Symbol table '.dynsym' contains entries with LOCAL visibility and type SECTION

[William Tambe]

On Sat, Mar 28, 2020 at 9:06 PM William Tambe <tambewilliam@gmail.com> wrote:
>
> On Sat, Mar 28, 2020 at 7:41 PM Fangrui Song <i@maskray.me> wrote:
> >
> > On 2020-03-26, William Tambe via Binutils wrote:
> > >On Thu, Mar 26, 2020 at 8:51 PM William Tambe <tambewilliam@gmail.com> wrote:
> > >>
> > >> What could be the reason that entries with LOCAL visibility and type
> > >> SECTION are showing in the symbol table '.dynsym' as shown below ?
> > >> What could be done to prevent that ?
> > >
> > >Please, note that this is a custom binutils port for which we are
> > >implementing shared-library support.
> > >We are missing something that is causing entries with LOCAL visibility
> > >and type SECTION to show in the symbol table '.dynsym' .
> > >
> > >What could be done to prevent such behavior ?
> > >
> > >>
> > >> Symbol table '.dynsym' contains 14 entries:
> > >>    Num:    Value  Size Type    Bind   Vis      Ndx Name
> > >>      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
> > >>      1: 000001f4     0 SECTION LOCAL  DEFAULT    5
> > >>      2: 00000216     0 SECTION LOCAL  DEFAULT    6
> > >>      3: 000003cc     0 SECTION LOCAL  DEFAULT    7
> > >>      4: 000013e8     0 SECTION LOCAL  DEFAULT    8
> > >>      5: 000013ec     0 SECTION LOCAL  DEFAULT    9
> > >>      6: 000013f4     0 SECTION LOCAL  DEFAULT   10
> > >>      7: 00001484     0 SECTION LOCAL  DEFAULT   12
> > >>      8: 0000149c     0 SECTION LOCAL  DEFAULT   14
> > >>      9: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND foo2
> > >>     10: 000001f4     0 FUNC    GLOBAL DEFAULT    5 _init
> > >>     11: 000003cc     0 FUNC    GLOBAL DEFAULT    7 _fini
> > >>     12: 00000364    42 FUNC    GLOBAL DEFAULT    6 func
> > >>     13: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND foo
> >
> > A STB_LOCAL .dynsym entry may be created if a dynamic relocation
> > references it.
> >
> > // a.c
> > char y;
> > struct{char _; const char *x; char *y;} __attribute__((packed)) _ = {'_', "a", &y};
> > void _start() {}
> >
> > % powerpc64-linux-gnu-gcc -shared -nostdlib a.c -o a.so
> > % readelf -Wr a.so
> >
> > Relocation section '.rela.dyn' at offset 0x288 contains 4 entries:
> >      Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
> > 000000000001fee8  0000000000000016 R_PPC64_RELATIVE                          2e8
> > 000000000001fef0  0000000000000016 R_PPC64_RELATIVE                          27f00
> > 0000000000020001  000000010000002b R_PPC64_UADDR64        00000000000002e8 .text + 28
> > 0000000000020009  000000040000002b R_PPC64_UADDR64        0000000000020011 y + 0
> >
> > R_PPC64_RELATIVE cannot be used because 0x20001 is misaligned.
> >
> > sh fdpic also needs it: http://git.musl-libc.org/cgit/musl/commit/?id=7a9669e977e5f750cf72ccbd2614f8b72ce02c4c
> >
> >
> > But if you see a lot of STT_SECTION in your custom port, I guess you triggered some bugs.
>
> elf_backend_finish_dynamic_section() is the last place we thought we
> could iterate through all symbols and remove unwanted symbols, but we
> can't see the STT_SECTION symbols there; that means they are added
> later.
>
> Any pointers on how we could further debug this issue ?

Or is there a specific breakpoint location where I can catch
STT_SECTION symbols being added and determine the cause ?