This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
gold's emission of _GLOBAL_OFFSET_TABLE_
- From: David Miller <davem at davemloft dot net>
- To: binutils at sourceware dot org
- Date: Mon, 07 Apr 2008 13:58:34 -0700 (PDT)
- Subject: gold's emission of _GLOBAL_OFFSET_TABLE_
Similarly to the other 2 existing targets, I emit this symbol on sparc
like this:
layout->add_output_section_data(".got", elfcpp::SHT_PROGBITS,
elfcpp::SHF_ALLOC | elfcpp::SHF_WRITE,
this->got_);
// Define _GLOBAL_OFFSET_TABLE_ at the start of the .got section.
symtab->define_in_output_data("_GLOBAL_OFFSET_TABLE_", NULL,
this->got_,
0, 0, elfcpp::STT_OBJECT,
elfcpp::STB_LOCAL,
elfcpp::STV_HIDDEN, 0,
false, false);
And it ends up in the symbol table like so:
Num: Value Size Type Bind Vis Ndx Name
...
26: 00011830 0 OBJECT LOCAL HIDDEN 23 _GLOBAL_OFFSET_TABLE_
Which differs from what the BFD linker does, at least on sparc and
several other platforms, which is:
Num: Value Size Type Bind Vis Ndx Name
...
59: 00011750 0 OBJECT LOCAL HIDDEN ABS _GLOBAL_OFFSET_TABLE_
I can't tell which one is right, using the .got section index or
SHN_ABS, perhaps the choice is arbitrary. Sun's linker seems to
behave the same as gold.
Looking at the BFD elf backends, i386 and x86_64 emit this symbol as
SHN_ABS when not targetting VXWORKS, just like sparc.
I also noticed that gold does not emit a _PROCEDURE_LINKAGE_TABLE_
symbol as the BFD linker does.