unreferenced local symbols generated in .dynsym

unreferenced local symbols generated in .dynsym

[Roland McGrath]

Doing:

    gcc -x c /dev/null -shared -nostdlib -o null.so -s
    readelf -Wsr null.so

shows:

    There are no relocations in this file.

    Symbol table '.dynsym' contains 15 entries:
       Num:    Value  Size Type    Bind   Vis      Ndx Name
	 0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
	 1: 00000094     0 SECTION LOCAL  DEFAULT    1 
	 2: 000000e4     0 SECTION LOCAL  DEFAULT    2 
	 3: 000001d4     0 SECTION LOCAL  DEFAULT    3 
	 4: 0000020c     0 SECTION LOCAL  DEFAULT    4 
	 5: 0000120c     0 SECTION LOCAL  DEFAULT    5 
	 6: 0000120c     0 SECTION LOCAL  DEFAULT    6 
	 7: 00001264     0 SECTION LOCAL  DEFAULT    7 
	 8: 00001270     0 SECTION LOCAL  DEFAULT    8 
	 9: 00000000     0 SECTION LOCAL  DEFAULT    9 
	10: 0000120c     0 OBJECT  GLOBAL DEFAULT  ABS _DYNAMIC
	11: 00001270     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
	12: 00001270     0 NOTYPE  GLOBAL DEFAULT  ABS _edata
	13: 00001264     0 OBJECT  GLOBAL DEFAULT  ABS _GLOBAL_OFFSET_TABLE_
	14: 00001270     0 NOTYPE  GLOBAL DEFAULT  ABS _end

There should never be local symbols in .dynsym unless they are referenced
by dynamic relocs.  Other superfluous symbols like the FILE symbol got
removed, but the section symbols remain no matter what I do.  This is buggy.

Re: unreferenced local symbols generated in .dynsym

[Ian Lance Taylor]

Roland McGrath <roland@redhat.com> writes:

> There should never be local symbols in .dynsym unless they are referenced
> by dynamic relocs.  Other superfluous symbols like the FILE symbol got
> removed, but the section symbols remain no matter what I do.  This is buggy.

A bit of a pain to fix in the general case, unfortunately.  The
section symbols are added by _bfd_elf_link_renumber_dynsyms(), which
is called by size_dynamic_sections().  At that point we want to know
the final size of all the dynamic sections.  However, at that point we
don't currently know which output sections will need relocs.  So we
just create a dynamic symbol for all the output sections.  I think
this is what the Solaris linker does as well.

To fix this we need new data structures to record which output
sections will need dynamic relocs, so that the dynamic symbol is
available when we get around to doing reloc processing.  Of course, in
ordinary cases we don't need a reloc against a dynamic section.  They
tend to be needed in cases where non-PIC code is linked into a shared
library, so we need to copy over the relocs but we don't necessarily
have a global symbol to hang them on.

Ian

Re: unreferenced local symbols generated in .dynsym

[Roland McGrath]

I am probably missing something.  I don't see why section symbols are ever
useful in .dynsym.  The layout is fixed by the time that's being made, so
relocs to sections can be converted to R_*_RELATIVE.  If there are relocs
of other types that require a symbol and can't be converted (non-wordsize
relocs for some architectures and so forth), then they can still be
converted to be relative to a single local symbol in .dynsym.  

Re: unreferenced local symbols generated in .dynsym

[Jakub Jelinek]

On Wed, Apr 23, 2003 at 12:13:40PM -0700, Roland McGrath wrote:
> I am probably missing something.  I don't see why section symbols are ever
> useful in .dynsym.  The layout is fixed by the time that's being made, so
> relocs to sections can be converted to R_*_RELATIVE.  If there are relocs
> of other types that require a symbol and can't be converted (non-wordsize
> relocs for some architectures and so forth), then they can still be
> converted to be relative to a single local symbol in .dynsym.  

E.g. shndx 0 which is mandatory.

	Jakub

Re: unreferenced local symbols generated in .dynsym

[Ian Lance Taylor]

Roland McGrath <roland@redhat.com> writes:

> I am probably missing something.  I don't see why section symbols are ever
> useful in .dynsym.  The layout is fixed by the time that's being made, so
> relocs to sections can be converted to R_*_RELATIVE.  If there are relocs
> of other types that require a symbol and can't be converted (non-wordsize
> relocs for some architectures and so forth), then they can still be
> converted to be relative to a single local symbol in .dynsym.  

Yes, the only issue is relocs which can not be converted to RELATIVE,
which is why it is primarily an issue when non-PIC objects are
included in a shared library.

You're right, it is possible to use a local symbol in .dynsym.
However, if you need one such symbol, you probably need more than one,
so why not use a section relative reloc?  Either way, we need some
sort of data structure to decide how many such symbols are required by
the time of size_dynamic_sections().  The information needs to be
computed in the processor specific check_relocs() routine, and used by
_bfd_elf_link_renumber_dynsyms() (or equivalent) and the the processor
specific relocate_section() routine.

Ian

Re: unreferenced local symbols generated in .dynsym

[Roland McGrath]

> You're right, it is possible to use a local symbol in .dynsym.
> However, if you need one such symbol, you probably need more than one,

Why?  Isn't one enough, converting any difference to addend?  It doesn't
matter to me if the local symbol is a section symbol or another flavor,
but I would like there to be only one.

Re: unreferenced local symbols generated in .dynsym

[Ian Lance Taylor]

Roland McGrath <roland@redhat.com> writes:

> > You're right, it is possible to use a local symbol in .dynsym.
> > However, if you need one such symbol, you probably need more than one,
> 
> Why?  Isn't one enough, converting any difference to addend?  It doesn't
> matter to me if the local symbol is a section symbol or another flavor,
> but I would like there to be only one.

Hmmm, you're right.  You should only need one symbol per section at
most, even without using section symbols.

Anyhow, I think we agree that the problem reduces to the same issue.
It's entirely doable, it's just that somebody has to do it.

Ian