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]

Re: st_shndx for ELF DSOs


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


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