Re: [ELF] symbol sets handling [2]

[Fabio Alemagna <falemagn at studenti dot unina dot it>]

On 12 Feb 2003, Ian Lance Taylor wrote:
> > Who said that? I said that I _would_ make symbol sets work the same way
> > c++ constructors/destructors are handled. Right now, of course, they are
> > handled differently.
>
> We are continuing to talk at cross-purposes.  I will try to be more
> clear about what I am saying.
>
> I am saying that the linker implementation of symbol sets is
> completely different from the linker implementation of C++
> constructors/destructors.

Ok, but I think we agreed about that (perhaps not in a very obvious
way...)... I just tried to outline the similarities between the approach
I'd take and the way constructors/destructors are handled now, just to
show that sorting the sections really can also mean sorting the symbols -
which was the main point we were discussing, if I'm not wrong.

> The point of my exhaustive description of
> how they work today was to show that they are handled completely
> differently.  They are handled by different code in different parts of
> the linker.  When you say that you would make them work the same way,
> that doesn't tell me very much.  And in fact, from my perspective as a
> linker implementor, it does not appear to be what you are proposing.

Perhaps I'm more focused on the conceptual design, rather than
implementation details, so that's why I find them similar: conceptually
they _are_ similar (I hope you agree about this...), they're just
implemented differently. However, finding similarities with
constructors/destructors was just an attempt at trying to show that
sorting sections can mean sorting symbols, and I hope that's clear now.

> I started to write responses to your comments on my implementation
> description, but I've removed them.  They don't seem to be relevant to
> the main issue at hand.  I'm talking about implementation details, and
> you are talking about conceptual approaches.

Exactly... we can say that there's been some communication problems :)

> To me, the key here is ``section names matching a given pattern.''
> What is that pattern?

Rigth now I use ".aros.set.<setname>.<setpri>". I decided to use ".aros"
for any AROS-specific section.

> How can we ensure that this system doesn't break an otherwise working
> link?

Well, surely with the ".aros" prefix I won't have any problems, also
because dot-prefixed section names are not meant by use of the general
programmer, or so I recall.

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

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

> > 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? In case you'd go for the latter, do you
still think that the ".gnu_symbol_set" approach should be taken, or have
you changed your mind about it? And if you haven't changed your mind, what
start and stop symbols do you suggest I should use, given the naming
conflict that would otherwise possibly arise?

Regards,
Fabio Alemagna