This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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: [RFC] allow -G to take a range


On Fri, Jun 13, 2003 at 05:58:50PM -0400, DJ Delorie wrote:
> 
> Ok, I'm working on some ideas for optimizing the use of .sdata, for
> cases where it's overflowing in a given application.  Here's the first
> one - allow the user to further limit the types of things that get put
> into .sdata.  This is untested, as I wanted to get some feedback about
> how well received this would be before putting the time into testing.
> 
> The idea here is that gcc will accept either "-Gn" or "-Gm-n", where
> m is the minimum (defaults to zero for compatibility) and n is the
> maximum.  Thus, one could specify "-G 4-4" to allow *only* 4-byte
> objects in .sdata, under the assumption that 1-byte and 2-byte objects
> are either not speed critical or cause wasted space in .sdata due to
> the alignment filler.

Note, if alignment holes are a big space waster, three thoughts come to mind.
One, use .sdata1 sections for 1 byte aligned items, and .sdata2 for 2 byte
aligned items.  Obviously this can't be done under ECOFF, with its fixed
section names.

The second thought is to have the linker sort items in a section based on
alignment.  This works for common variables created by the linker, but less
well for initialized variables that are just plunked into the current .sdata
section.

The third thought would be to have the compiler not put things like strings &
constants in the .sdata/.lit* sections.

Off hand, I suspect that there are few 8-bit and 16-bit aligned items other
than small character strings.

-- 
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org


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