Symbol table '.dynsym' contains entries with LOCAL visibility and type SECTION
William Tambe
tambewilliam@gmail.com
Sun Mar 29 01:06:34 GMT 2020
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 ?
More information about the Binutils
mailing list