[ELF] symbol sets handling [2]

[Ian Lance Taylor]

Fabio Alemagna <falemagn@studenti.unina.it> writes:

> > It would be very bad if the linker
> > started unexpectedly rearranging sections.  For example, it's
> > certainly not safe to assume that you can rearrange any section whose
> > name happens to match the regexp *[.][0-9]+
> 
> Actually the regexp is more restrictive than the above one, allowing only
> for C-representable section names, with the optional dot and pri number,
> however it's still a quite large range, sure. But I cannot think of a
> reason for why would the rearranging of sections matter in any way, since
> there's no guarantee that the sections are kept in any specific order,
> unless the linker script specifies otherwise..

Some programs rely on the fact that code is linked in the order in
which the object files are listed on the command line.  Programs
probably shouldn't rely on that, but linkers have always behaved that
way, and changes to it must be done with care.

> > That is why I suggested that the section names to be rearranged must
> > have names starting with ".gnu_symbol_set", although of course it
> > could be any other relatively unique string.
> 
> Ok, for me that's fine, I just didn't think it was necessary to invent
> another way to basically do what's just an extension of what is available
> now. However, in case the ".gnu_..." approach has to be taken, then
> another kind of start and stop symbols naming convention has to be used,
> since it could happen that the object files both contain a
> ".gnu_symbol_set.<setname>" section and a normal "<setname>" section,
> leading to a double definition of the same __start and __stop symbols.
> Perhaps I could use "__aros_start" and "__aros_stop"...

I wouldn't worry too much about the double definition problem.  It is
rare to find an ELF section whose name can be represented as a C
identifier, which is why I thought it was safe to introduce the
__start and __stop symbols.  If you want to be very careful, I would
recommend simply something like __gnu_symbol_set_start_NAME.

> > > Yes, that I know, the problem is: how do I do the sorting? Should I do it
> > > by hand (meaning  should I implement it from scratch), or can I somehow
> > > use the SORT() ld command?
> >
> > Given that the emulation is going to see input sections with names
> > matching the pattern one at a time, and given that we can assume there
> > will not be an extraordinary number of input sections with names
> > matching the pattern, I would recommend a simple insertion sort in
> > place_orphan.  That is, as you see each input section, just put it in
> > the right place.  This is, in fact, how the SORT keyword is
> > implemented anyhow (see wild_sort() in ldlang.c), so it's not like it
> > would be any less efficient than creating a bit of linker script on
> > the fly.
> 
> Ok, I'll do it that way then... One last thing: should I implement it for
> my own target only (.aros.set.<setname>.<setpri>>, or should I implement
> it for the general elf target?

This is a question for the current maintainers, but my advice would be
to do it for the general ELF target.  If we're going to have the code
in the GNU binutils anyhow, it might as well be available in case
other people want to use it.

Ian