st_shndx for ELF DSOs

st_shndx for ELF DSOs

[Jakub Jelinek]

Hi!

When creating an ELF DSO, ld uses SHN_ABS quite often for linker created
symbols (like _PROCEDURE_LINKAGE_TABLE_, _GLOBAL_OFFSET_TABLE_, _DYNAMIC,
___start_FOO, ___stop_FOO etc).
But this unfortunately means information loss, because any post-ld utility
is not able to differentiate between real *ABS* section symbols and section
symbols which are relative to base VMA.
Looking at other linkers, e.g. on Solaris all those symbols get a st_shndx
of the section they point into (the question is what to do with symbols
which don't point into any particular section).
For the bfd generated symbols SHN_ABS usually overwrites the actual
output section (code like:
  /* Mark some specially defined symbols as absolute.  */
  if (strcmp (h->root.root.string, "_DYNAMIC") == 0
      || strcmp (h->root.root.string, "_GLOBAL_OFFSET_TABLE_") == 0
      || strcmp (h->root.root.string, "_PROCEDURE_LINKAGE_TABLE_") == 0)
    sym->st_shndx = SHN_ABS;
) in arch elf processing - any reason why is this done? - but these could be
handled specially. The bigger problem is the rest of the ABS symbols which
are not actually absolute and are either defined in the linker script or
e.g. in elf32.em (such as ___start_* and ___stop_*) - here symbols defined
outside of output section statements get absolute_section.
Any ideas what could be done for this?
Something like marking the initial . = assignment in the linker script with
RELOCATABLE(. = 0x...... + SIZE_OF_HEADERS) and then any symbol which would
get assigned a RELOCATABLE address (e.g. depend on `.' if `.' depends on
something RELOCATABLE) would be put into this special section and not
absolute_section (that section would be actually equal to absolute_section
unless doing DSO final link). This special section would resolve into
closest output section's st_shndx.

	Jakub

Re: st_shndx for ELF DSOs

[amodra]

On Thu, May 17, 2001 at 04:50:29PM +0200, Jakub Jelinek wrote:
> Looking at other linkers, e.g. on Solaris all those symbols get a st_shndx
> of the section they point into (the question is what to do with symbols
> which don't point into any particular section).

Do you know what the dynamic linker on Solaris does with SHN_ABS syms?

Re: st_shndx for ELF DSOs

[Nick Clifton]

Hi Jakub,

> Something like marking the initial . = assignment in the linker script with
> RELOCATABLE(. = 0x...... + SIZE_OF_HEADERS) and then any symbol which would
> get assigned a RELOCATABLE address (e.g. depend on `.' if `.' depends on
> something RELOCATABLE) would be put into this special section and not
> absolute_section (that section would be actually equal to absolute_section
> unless doing DSO final link). This special section would resolve into
> closest output section's st_shndx.

So essentially you are proposing that the linker create a special
section which could be used as the value for the st_shndx index for
any symbol which is present in the output, is intended to be
relocatable, and which does not already have a section associated with
it ?

How could such symbols exist ?  ie How can a symbol be relocatable and
yet not be referencing something in one of the sections of the output?

The __start_* and __stop_* symbols that you mention for example are
associated with the being and end addresses of particular sections, so
presumably their st_shndx ought to point to their particular section.

I think that I agree that only symbols that are truly absolute should
have SHN_ABS for their index, but I am not sure that the linker should
be creating a special section for the others.  I think it ought to be
setting their section index appropriately.

Cheers
        Nick

Re: st_shndx for ELF DSOs

[Jakub Jelinek]

On Wed, May 23, 2001 at 06:16:12PM +0100, Nick Clifton wrote:
> Hi Jakub,
> 
> > Something like marking the initial . = assignment in the linker script with
> > RELOCATABLE(. = 0x...... + SIZE_OF_HEADERS) and then any symbol which would
> > get assigned a RELOCATABLE address (e.g. depend on `.' if `.' depends on
> > something RELOCATABLE) would be put into this special section and not
> > absolute_section (that section would be actually equal to absolute_section
> > unless doing DSO final link). This special section would resolve into
> > closest output section's st_shndx.
> 
> So essentially you are proposing that the linker create a special
> section which could be used as the value for the st_shndx index for
> any symbol which is present in the output, is intended to be
> relocatable, and which does not already have a section associated with
> it ?
> 
> How could such symbols exist ?  ie How can a symbol be relocatable and
> yet not be referencing something in one of the sections of the output?
> 
> The __start_* and __stop_* symbols that you mention for example are
> associated with the being and end addresses of particular sections, so
> presumably their st_shndx ought to point to their particular section.
> 
> I think that I agree that only symbols that are truly absolute should
> have SHN_ABS for their index, but I am not sure that the linker should
> be creating a special section for the others.  I think it ought to be
> setting their section index appropriately.

I got around it for the time being by relocating all SHN_ABS symbols in
DSOs with the exception of those with st_value 0.
The dynamic linker relocates all .dynsym symbols which are referenced,
st_value 0 SHN_ABS symbols are usually special things (like versioning
symbols etc.) aren't used in relocations.
With this rule, at least all DSOs I've tried had identical symbol table if
they were linked normally and relocated later to some base VMA or if ld was
already linking it to that VMA.
This would not work if some DSO wanted to have a symbol pointing to
library's ElfW(Ehdr), but AFAIK nobody does that.

	Jakub