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: [rfc] allow -G to take a range


On Tue, May 27, 2003 at 10:31:44PM -0400, DJ Delorie wrote:
> 
> > Also, you don't know until link time which globals have been
> > initialized, which are common decls, and which aren't referenced and
> > not linked in with the appropriate switches.  Statics are easier.
> > Once we switch over to whole file at a time (tree-ssa?) the compiler
> > will know which things to emit.
> 
> But gcc needs to know if it can use gprel addressing or not, right?
> So it must be the one deciding what goes in sdata and what doesn't.

Usually, but the MIPS for instance does it in the assembler.  If you keep the
relocations around for all branches (even for branches within the same
segment), and have at least one scratch register, you could always do it in the
linker with code relaxation.  Of course the code relaxation code is fairly
hairy.

> > By the way, you can already do this with TARGET_ASM_SELECT_SECTION,
> > TARGET_ENCODE_SECTION_INFO, and friends.
> 
> Right, but I didn't tell you everything (sorry).  I'm trying to solve
> this without requiring link script changes, because this is for an
> existing project and changing the link script might not be an option.

That does make it harder, unless the original linker script used wildcards (ie,
using .sdata* instead of .sdata).

> > I was thinking more for globals, where they already are their own
> > section.  But it is simple enough to create such sections for
> > statics too.
> 
> Why would globals be in their own section?  If they're initialized,
> they're all lumped into .data, right?

But not all globals are initialized.  Those that aren't initialized are
allocated by the linker.  Those that are initialized, are placed by the
compiler into an appropriate segment (presumably .sdata).  This is one of the
problems with -Gn, in that you have to make sure all modules get compiled with
the same switch.  I remember when I worked at Red Hat, the 'fun' of tracking
through newlib to make sure I caught all of the globals referenced and put them
into .sdata, without compiling the rest of newlib with -Gn, so that their data
wouldn't contribute too much to the sdata area.

> > Yep.  The first pass will be having .sdata1, .sdata2, .sdata4, etc. and the
> > linker script just links .sdata1 first, then .sdata2, etc.  That is easy.
> > After that I need to either have the linker distribute things, or have parallel
> > .sdata sections (ie, .sdatan1, .sdatan2, etc.) that are for negative offsets,
> > and just have the user assign the variables there directly.
> 
> Hmmm... PE already has logic for stuff like .sdata$4 where everything
> after the '$' is automagically sorted and stripped by the linker.  I
> wonder if that would help us here?  We'd need some sort of reverse
> sort for your case, though.

For me, that is far down the pike.  If everything is in its own section, it
makes it simpler for the linker to properly allocate the things.

> > The rs6000/powerpc and V850 ports already allow the user to use:
> > 
> > 	__atribute__((__section__("str")))
> > 
> > to hardwire the sections.  IIRC, the V850 had 3 small data areas.
> 
> I think most ports support user-named sections.
> 
> Note that the mips backend has extra logic to detect when you assign a
> variable to the sdata/sbss section.  That would have to be expanded if
> we add more types of sdata/sbss subsections.

-- 
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]