This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH-H8300] Handling tiny_data attribute


>Asgari J. Jinia wrote:
>
>>Following patch was created by Grant Edwards for gcc 3.3
>>branch. I have made it suitable for gcc 3.4-20040325 sources.
>>Can it be applied to current gcc-3.4 branch and mainline? 
>
>We need a copyright assignment from Grant Edwards then. I
>believe KPIT Cummins has a blanket assignment, so your
>contribution is OK.

I have requested "the relevent forms" for a copyright
assignment.

As far as the comments below, I will attempt to address them.

Somebody will have to send me a copy of the patch.  The mailing
list web archive doesn't seem to have a way to retrieve
unmolested messages.

>h8300_section_type_flags is missing an explanatory comment
>before it. It is an old style function definition. We want ISO
>C prototype-style function definitions only.

OK. I can fix that.  I a little confused, though. None of the
other functions in my gcc sources have ISO prototypes.

>In h8300_handle_tiny_data_attribute, you have a blank line
>after an open brace. Two spaces in "size_t plen" should be one.

I can fix that.

>Changing .tiny sections support won't work without appropriate
>binutils support.

I'm using it without any binutils changes and it works just fine.

>You need to add the new sections into the linker scripts first,
>before modifying gcc.

I'll try to do that, but I really don't see the point.  This
feature is useless to anybody who isn't doing embedded systems
work. They aren't going to be using the default linker script
since it hasn't a clue how the target hardware is layed out.

IMO, you're better off getting an error if you use the default
linker script than you are getting an output file with all your
sections in the wrong places.

BTW, what target platform is the default linker script for?

>Otherwise, this feature will stop working. There are also
>timing/documentation issues, since you need to wait for a
>binutils release, and/or document the dependence on the
>binutils change.

>It might be easier to provide default section flags for the
>tiny section rather than letting gcc compute them.

Sorry, I don't know what that means.

>That way you wouldn't have to split it into 3 sections, and
>hence would not need linker script changes. I don't know if
>this is feasible, I did not check.

The whole point of the exercise was to create three different
sections, so I don't really understand what you're suggesting.
Will "default section flags" provide a way for "tiny" variables
to be placed into three separate sections?

 1) Read only-data in address region A
 2) Initialized R/W data in address region B
 3) Uninitialized R/W data in address region B

>Grepping, I do not see any targets which use
>flag_data_sections, so checking it in h8300.c seems wrong.

Perhaps it isn't needed at all.  I'll take it out and see what
happens.

>Maybe there is a way to get the machine independent code to do
>this for us?

I don't even know what it does. ;) The other code that
generates section names does it that way, and I copied it.

-- 
Grant Edwards
grante@visi.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]