[PATCH] gold/arm: define $a/$d markers in .plt
Wed Apr 25 19:00:00 GMT 2012
From: Cary Coutant <firstname.lastname@example.org>
Date: Wed, 25 Apr 2012 11:14:16 -0700
> How about instead adding a "force_local" flag to these three
> functions, then using STB_GLOBAL with force_local == true for
> _GLOBAL_OFFSET_TABLE_ and similar symbols? I think it's misleading to
> use STB_LOCAL for a symbol that actually does have global scope
> (within the link).
BTW, this reminds me of something I noticed while working on Sparc
GOLD downgrades a protected symbol from STB_GLOBAL to STB_LOCAL in the
final link, which I've not seen the BFD linker do.
This has potential implications on sparc, because STB_LOCAL symbols
have their relocations calculated differently than STB_GLOBAL ones
in the dynamic-linker.
The difference is that for STB_LOCAL symbols, the dynamic-linker
assumes that the symbol value is present in the relocation's addend.
Therefore it uses the map address as the relocation value for this
This is why I have that test on gsym->forced_local() in the
Target_sparc::Scan::global() code which is trying to figure out
whether we should use R_SPARC_GLOB_DAT or not.
I even added an assertion and detailed comment to that code explaining
|| (gsym->type() == elfcpp::STT_GNU_IFUNC
unsigned int r_type = elfcpp::R_SPARC_GLOB_DAT;
// If this symbol is forced local, this relocation will
// not work properly. That's because ld.so on sparc
// (and 32-bit powerpc) expects st_value in the r_addend
// of relocations for STB_LOCAL symbols. Curiously the
// BFD linker does not promote global hidden symbols to be
// STB_LOCAL in the dynamic symbol table like Gold does.
got->add_global_with_rel(gsym, GOT_TYPE_STANDARD, rela_dyn,
Is it really such a good idea to perform this change from STB_GLOBAL
to STB_LOCAL for symbols with protected visibility? What does it buy
More information about the Binutils