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]


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.

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.




> Consider:
>     symbol set I
>         symbol d
>         symbol e
>         symbol f
>     symbol set II
>         symbol x
>         symbol y
>         symbol z
>
> Do you want to control the order of symbol set I and symbol set
> II--e.g., arrange for symbol set II to appear before symbol set I?  Or
> do you want to control the order of the symbols within the symbol
> sets--e.g., arrange for f to precede d and/or z to precede x?

As said, the linker would order the sections, but the effect is the same
as ordering the symbols, since all symbols with the same priority go in
the same section and all symbols with different priorities go in different
sections.

> Have you considered not relying on the linker to do the sorting, but
> to have each symbol in the set be the address of a structure
> containing the priority and the function to call?  Then you can sort
> the symbols in the correct order before you call them; inelegant but
> simple.

You said it: inelegant, not o mention wasteful (cpu time and disk/memory
space). Right now I do it with the linker already, trough the help of a
postprocessor (it searches for section names matching a specific pattern
and emits ld script snippets to handle the proper symbol sets, then these
snippets are inserted in a real ld script and the script is fed to ld).


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

Fabio Alemagna


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