This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] gold/arm: define $a/$d markers in .plt


From: Cary Coutant <ccoutant@google.com>
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
IFUNC support.

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
case.

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
this situation:

--------------------
		|| (gsym->type() == elfcpp::STT_GNU_IFUNC
		    && parameters->options().output_is_position_independent()
		    && !gsym->is_forced_local()))
	      {
		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.
		gold_assert(!gsym->is_forced_local());
		got->add_global_with_rel(gsym, GOT_TYPE_STANDARD, rela_dyn,
					 r_type);
	      }
--------------------

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
us?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]