http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #31 from Rich Felker <bugdal at aerifal dot cx> 2012-04-29 04:39:03
UTC ---
I think part of the difficulty of this issue is that the behavior of protected
is not well-specified. Is it intended to prevent the definition from
interposition? Or is it promising the compiler/toolchain that you won't
override the definition (and acquiescing that the behavior will be undefined if
you break this promise)?
If protected's intent is the former, then it's absolutely wrong to resolve the
function's address to the main executable's PLT entry for a different function
by the same name. To avoid this, the GOT entry for the function in the shared
library must point to the PLT entry in the main program if and only if the main
program's symbol got resolved to the library's version of the function;
otherwise, it must point to the library's version. I don't see an easy way to
arrange this without special help from the dynamic linker, and personally, I
think it's a slippery slope to try to make promises that are this difficult to
keep.
As such I'd prefer that protected's behavior be the latter: an optimization
hint to the compiler in the form of a promise not to override the definition.
In any case, I'm experiencing this bug in the form of not being able to take
the address of any external functions when using -fvisibility=protected, and
it's making it impossible to use -fvisibility=protected. I get bogus linker
errors about not being able to use a protected function for R_386_GOTOFF
relocations. So I want to see this solved in one way or another, preferably in
the way that results in maximal performance and minimal bloat while ensuring
correct behavior as long as the functions are not overridden...
