This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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: [ELF] symbol sets handling [2]


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

> On 8 Feb 2003, Ian Lance Taylor wrote:
> > You say that you do want to sort a collection of symbol set sections,
> > but your examples appear to be ones of sorting symbols within a single
> > symbol set section.
> 
> It's the same thing, really, for how it works: all symbols with the same
> priority go in the same section, and all symbol with different priorities
> go in different sections (each one differing by the priority suffix), then
> the SORT() ld command is used to sort those sections.

I'm trying to ask what you want to achieve in the final program.  It
seems clear to me that the two cases are not the same.  The way to
achieve one goal is not the way to achieve a different goal.

> It's just like it happens with c++ constructors/destructors, something
> that already works with ld (look at the .ctors/.dtors sections in your ld
> script), I'm not inventing anything new, I'd just like to make it work
> with general symbol sets.

C++ constructors/destructors in ELF are not handled in the same way
that what I think of as symbol sets are handled.  So perhaps we are
talking at crosspurposes.

I'm going to go over how these things work in detail.  I know that you
know this information.  I'm doing it because I can't figure out what
you want.  I understand that you want prioritized symbol sets.  But
that is an imprecise statement which can be interpreted in many
different ways.  I want to understand what you want in precise terms.

The common elements of C++ constructors/destructors and symbol sets
are this: they are a simple list of symbols, such that the program at
runtime can easily find the start of the list and length or the end of
the list.

C++ constructors/destructors in ELF work because they are explicitly
called out in the linker script.  For historical reasons, the compiler
cooperates by using two object files: crtbegin.o and crtend.o.  These
object files define the special symbol which marks the start of the
constructor/destructor lists (__CTOR_LIST__ and __DTOR_LIST__).  For
historical reasons, the lists start with -1 and end with 0.  The
program refers to the appropriate symbol, skips the first entry, and
moves down the list until it finds a zero.

The compiler puts all C++ constructors/destructors in sections with
particular names: .ctors and .dtors.  When a constructor/destructor
has a priority, the compiler includes the priority in the name of the
section, e.g. .ctors.PRI.  The linker includes all such sections,
sorted, in the final .ctors or .dtors section.  This happens because
of explicit SORT statements in the linker script.

That's how C++ constructors/destructors work.  Symbol sets, at least
what I call symbol sets, work in a completely different fashion.

To implement symbol sets, the linker provides a simple enhancement.
The linker already naturally groups all input sections with the same
name together.  That is, all input sections named .foo will be grouped
together into a single output section named .foo.  The support for
symbol sets is this: if the output section name can be represented as
a C identifier, then the linker will automatically define special
symbols which the program may use at runtime to identify the start and
end of the output section.

This feature may be used in a variety of ways.  To use it to implement
symbol sets, the program will normally define a section which contains
only the value of a symbol.  The linker will group all sections with
the same name together, and the program can then at runtime use the
specially defined symbol to find the set of all symbols with the same
name.

This feature permits an arbitrary number of symbol sets, without
requiring them to be explicitly called out in the linker script.  Note
that the program must normally still be aware of the name of each
interesting symbol set (although one could imagine building a set of
symbol sets).


Anyhow, as can be seen, there are two different mechanisms for two
different results.

> > If you must do it in the linker, then I suppose you are on the right
> > track by putting the priority into the section name, but you will need
> > to have some way for the linker to detect that it should emit the
> > __start and __stop symbols.  For example, you could invent some code
> > to be embedded in the section name, e.g.
> >     .gnu_symbol_set.NAME.PRIORITY
> > When the emulation sees a section of that names, it groups them,
> > sorted by priority (simpler if this can be done lexically) and emits
> > the __start and __stop symbols using NAME.
> 
> 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?

Remember that right now the linker does not know anything about symbol
sets, at least as I define them.  What the linker knows is that when a
section can be named as a C identifier, it will define a __start and
__stop symbol.

> My
> problem is that I'm not sure how to handle the "extended" situation... How
> would you do it in case I had to use ".gnu_symbol_set"?

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.

Ian


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