This is the mail archive of the 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

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

> By the way, you can already do this with TARGET_ASM_SELECT_SECTION,

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.

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

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

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

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