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] |
I have attached a patch to add --weak-unresolved-symbols to gold. Please let me know what you think. Thanks Sri On Sat, Apr 11, 2015 at 6:28 AM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Fri, Apr 10, 2015 at 7:18 PM, Cary Coutant <ccoutant@gmail.com> wrote: >>> However, with -fPIE >>> >>> $ g++ -O2 -fPIE foo.cc -pie >>> foo.cc:function main: warning: undefined reference to 'foo()' >>> >>> but >>> $./a.out >>> ./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 >>> reasonable? >> >> 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? >> > > This sounds reasonable to me. > > -- > H.J.
Attachment:
weak_unresolved_symbols_patch.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |