Simon Atanasyan via llvm-dev
2016-Feb-08 14:22 UTC
[llvm-dev] [LLD] Is there any reason to add _GLOBAL_OFFSET_TABLE_ to .dynsym?
When LLD builds a shared library for x86_64 it puts _GLOBAL_OFFSET_TABLE_ to the both .symtab and .dynsym and defines it as a GLOBAL symbol. If later this shared library participates in executable file linking and GNU BFD linked is used for that, this linker shows an error: /usr/bin/ld: a.out: hidden symbol `_GLOBAL_OFFSET_TABLE_' in /usr/lib/x86_64-linux-gnu/crt1.o is referenced by DSO Gold linker does not show any error, but it is anyway strange that we make _GLOBAL_OFFSET_TABLE_ globally visible and add it to dynamic symbol table. Both BFD and Gold linker do not put _GLOBAL_OFFSET_TABLE_ to the dynamic symbol table and defines this symbol as follows: BFD: Num: Value Size Type Bind Vis Ndx Name 42: 0000000000200990 0 OBJECT LOCAL DEFAULT ABS _GLOBAL_OFFSET_TABLE_ Gold: Num: Value Size Type Bind Vis Ndx Name 19: 0000000000001a18 40 OBJECT LOCAL HIDDEN 19 _GLOBAL_OFFSET_TABLE_ -- Simon Atanasyan
Rui Ueyama via llvm-dev
2016-Feb-10 00:43 UTC
[llvm-dev] [LLD] Is there any reason to add _GLOBAL_OFFSET_TABLE_ to .dynsym?
I think that there's no reason to add that symbol to .dynsym. If it is causing a problem, we should remove that. On Mon, Feb 8, 2016 at 6:22 AM, Simon Atanasyan <simon at atanasyan.com> wrote:> When LLD builds a shared library for x86_64 it puts > _GLOBAL_OFFSET_TABLE_ to the both .symtab and .dynsym and defines it > as a GLOBAL symbol. If later this shared library participates in > executable file linking and GNU BFD linked is used for that, this > linker shows an error: > > /usr/bin/ld: a.out: hidden symbol `_GLOBAL_OFFSET_TABLE_' in > /usr/lib/x86_64-linux-gnu/crt1.o is referenced by DSO > > Gold linker does not show any error, but it is anyway strange that we > make _GLOBAL_OFFSET_TABLE_ globally visible and add it to dynamic > symbol table. > > Both BFD and Gold linker do not put _GLOBAL_OFFSET_TABLE_ to the > dynamic symbol table and defines this symbol as follows: > > BFD: > Num: Value Size Type Bind Vis Ndx Name > 42: 0000000000200990 0 OBJECT LOCAL DEFAULT ABS > _GLOBAL_OFFSET_TABLE_ > > Gold: > Num: Value Size Type Bind Vis Ndx Name > 19: 0000000000001a18 40 OBJECT LOCAL HIDDEN 19 > _GLOBAL_OFFSET_TABLE_ > > -- > Simon Atanasyan >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/f3f9982f/attachment.html>
Joerg Sonnenberger via llvm-dev
2016-Feb-10 13:22 UTC
[llvm-dev] [LLD] Is there any reason to add _GLOBAL_OFFSET_TABLE_ to .dynsym?
On Mon, Feb 08, 2016 at 05:22:03PM +0300, Simon Atanasyan via llvm-dev wrote:> When LLD builds a shared library for x86_64 it puts > _GLOBAL_OFFSET_TABLE_ to the both .symtab and .dynsym and defines it > as a GLOBAL symbol.It shouldn't put it into .dynsym. It can be useful in .symtab for debugging purposes. Joerg
Rafael EspĂndola via llvm-dev
2016-Feb-11 03:56 UTC
[llvm-dev] [LLD] Is there any reason to add _GLOBAL_OFFSET_TABLE_ to .dynsym?
How is it used, btw? To me it looked to be a gas hack that became visible. R_386_GOTPC and similar should be able to just use an r_sym of 0, no? But in lld we have to handle current files with _GLOBAL_OFFSET_TABLE_, and yes, no objections do dropping it from any table. Cheers, Rafael On 10 February 2016 at 08:22, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On Mon, Feb 08, 2016 at 05:22:03PM +0300, Simon Atanasyan via llvm-dev wrote: >> When LLD builds a shared library for x86_64 it puts >> _GLOBAL_OFFSET_TABLE_ to the both .symtab and .dynsym and defines it >> as a GLOBAL symbol. > > It shouldn't put it into .dynsym. It can be useful in .symtab for > debugging purposes. > > Joerg > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev