Re: [ELF] symbol sets handling [2]

[Ian Lance Taylor <ian at airs dot com>]

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

> > C++ constructors/destructors in ELF are not handled in the same way
> > that what I think of as symbol sets are handled.
> 
> 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.  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.

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.

> That's basically how I do it now, except that the ld script's pieces that
> build the sets are automatically generated by a post processing tool. This
> tool acts like a wrapper around ld: it first invokes ld on the given files
> with the -r flag, then it feeds the generated file to objdump, then the
> output of objdump is searched for section names maching a given pattern,
> from these section names the set name is extracted and ld script snippets
> generated, these snippets are then merged into a preexisting ld script and
> the resulting ld script is fed to ld, together with the previously
> generated object file, and a final link is done.

To me, the key here is ``section names matching a given pattern.''
What is that pattern?  How can we ensure that this system doesn't
break an otherwise working link?  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]+

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.

> > > That's what I proposed... But there's no need for ".gnu_symbol_set", it
> > > can be done just by extending the way symbol sets are handled now.
> >
> > What do you mean by this?  In what way would you extend the way symbol
> > sets are handled now?  Can you write down precisely the steps you
> > propose that the linker should take?
> 
> If I knew the steps the linker should take I would have implemented it
> already, don't you think? :) The thing is that I don't know how to
> implement it in the emulation script, so I don't know which steps
> should ld take, however I showed above how I'd like it to work.

The description of how you would like it to work is your answer to my
question of what steps the linker should take.  You had never before
described precisely what you wanted to happen.  I knew that you
understood what you wanted to happen, but you hadn't explained it to
me.

> > Well, guessing at what you want to achieve, I would say that when the
> > place_orphan function sees an orphan section whose name starts with
> > .gnu_symbol_set, it sets the output section name by dropping the
> > PRIORITY field.  It defines __start and __stop symbols based on the
> > NAME field.  It then places the input section in the output section
> > sorted by the full input section 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.

Ian