Summary: | bad GOT reloc generation in -shared for STV_PROTECTED with primary PLT/copy reference | ||
---|---|---|---|
Product: | binutils | Reporter: | Roland McGrath <roland> |
Component: | gold | Assignee: | Ian Lance Taylor <ian> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 2.22 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Roland McGrath
2011-07-09 22:59:17 UTC
CVSROOT: /cvs/src Module name: src Changes by: ian@sourceware.org 2011-07-12 22:29:09 Modified files: gold : ChangeLog i386.cc x86_64.cc gold/testsuite : protected_1.cc protected_main_1.cc Log message: PR gold/12980 * i386.cc (Target_i386::Scan::global): For a GOT reloc, use a GLOB_DAT relocation rather than a RELATIVE relocation for a protected symbol when creating a shared library. * x86_64.cc (Target_x86_64::Scan::global): Likewise. * testsuite/protected_1.cc (f2, get_f2_addr): New functions. * testsuite/protected_main_1.cc (main): Test that protected function has same address. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.803&r2=1.804 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/i386.cc.diff?cvsroot=src&r1=1.138&r2=1.139 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/x86_64.cc.diff?cvsroot=src&r1=1.136&r2=1.137 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/protected_1.cc.diff?cvsroot=src&r1=1.1&r2=1.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/protected_main_1.cc.diff?cvsroot=src&r1=1.1&r2=1.2 I'm not convinced that this case is very interesting. The test fails when using gcc's visibility attribute, because in that case gcc generates a PC-relative reloc (on x86_64) and there is no way that the function addresses can match. It only works for glibc because glibc uses .protected in an asm rather than using the visibility attribute. On the other hand, for the same reason, it doesn't cost very much; normal code will never use a GOT entry for a protected variable. So I went ahead and implemented this in gold in the spirit of keeping glibc happy. I tend to think that the aforementioned GCC behavior is a bug. But I haven't looked at the spec for visibility handling lately. At any rate, it is a Good Thing for such subtleties to have the same behavior in both ld implementations. So if this glibc test's expectation is actually wrong, then BFD ld should be fixed instead. |