This is the mail archive of the
mailing list for the binutils project.
Re: Patch to not create GOT and dynamic relocation entries for unresolved symbols with --warn-unresolved-symbols.
- From: Cary Coutant <ccoutant at gmail dot com>
- To: Sriraman Tallam <tmsriram at google dot com>
- Cc: binutils <binutils at sourceware dot org>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Rong Xu <xur at google dot com>, Brooks Moses <bmoses at google dot com>, Ollie Wild <aaw at google dot com>, David Li <davidxl at google dot com>, Teresa Johnson <tejohnson at google dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Ian Lance Taylor <iant at google dot com>
- Date: Fri, 10 Apr 2015 19:18:06 -0700
- Subject: Re: Patch to not create GOT and dynamic relocation entries for unresolved symbols with --warn-unresolved-symbols.
- Authentication-results: sourceware.org; auth=none
- References: <CAAs8Hmxe3fNV-7MLyNhk_=DOaR91-s=dFw3E-cFdqCCiGxxreA at mail dot gmail dot com>
> However, with -fPIE
> $ g++ -O2 -fPIE foo.cc -pie
> foo.cc:function main: warning: undefined reference to 'foo()'
> ./a.out: symbol lookup error: ./a.out: undefined symbol: _Z3foov
> because with fPIE, a function pointer access is using a GOTPCREL
> relocation which creates a GOT entry and a dynamic relocation for it.
> The dynamic linker does not like the unresolved symbol any more.
> I have attached a patch to prevent creation of GOT and dynamic
> relocation entries with --warn-unresolved-symbols in general. Is this
No, I don't think so. For static links, we statically resolve
undefined symbols to zero, but for non-static links, we leave them for
dynamic resolution, presuming that they might be resolvable at
runtime. This patch would change linker behavior that is fairly well
established. (This patch also changes only x86_64 behavior; you'd need
a similar patch for all targets. For a problem that isn't really
target-specific, I'd prefer a target-independent solution.)
The difference between non-PIE and PIE here is not due to the linker's
-pie option, but because the compilers -fPIE option caused the
compiler to use the GOTPCREL relocation, which requires the linker to
create a GOT entry.
If the reference to foo is weak, the dynamic loader won't complain --
I think that's really what you want. I'm not sure whether it's
reasonable for you to have the compiler make these symbols weak unsats
or not, but if you can, you wouldn't need --warn-unresolved-symbols
any longer. If not, I wouldn't object to a new
--weak-unresolved-symbols option that would have the linker convert
any unresolved symbols (that it warned about) into weak references. I
don't think we want to do that by default, since it changes existing
expectations, but I think it's fine as an option.
HJ, does that sound like a reasonable option for Gnu ld as well?