[Bug ld/15167] ld merges gnu_unique def and normal ref into normal symbol
http://sourceware.org/bugzilla/show_bug.cgi?id=15167 --- Comment #2 from cvs-commit at gcc dot gnu.org 2013-02-22 01:20:55 UTC --- CVSROOT:/cvs/src Module name:src Changes by:h...@sourceware.org2013-02-22 01:20:48 Modified files: ld/testsuite : ChangeLog ld/testsuite/ld-unique: unique.exp bfd: ChangeLog elf64-ia64-vms.c elflink.c Log message: Set unique_global only for definition bfd/ PR ld/15167 * elf64-ia64-vms.c (elf64_vms_link_add_object_symbols): Set unique_global only for definition. * elflink.c (_bfd_elf_merge_symbol): Don't set unique_global here. (elf_link_add_object_symbols): Set unique_global only for definition. ld/testsuite/ PR ld/15167 * ld-unique/unique.exp: Add a test for shared library with reference. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ChangeLog.diff?cvsroot=src&r1=1.1690&r2=1.1691 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-unique/unique.exp.diff?cvsroot=src&r1=1.3&r2=1.4 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5980&r2=1.5981 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf64-ia64-vms.c.diff?cvsroot=src&r1=1.7&r2=1.8 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?cvsroot=src&r1=1.471&r2=1.472 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15167] ld merges gnu_unique def and normal ref into normal symbol
http://sourceware.org/bugzilla/show_bug.cgi?id=15167 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from H.J. Lu 2013-02-21 19:12:37 UTC --- [hjl@gnu-6 pr15167]$ cat unique_shared1.s .type b, %gnu_unique_object b:.long 0 .size b, .-b [hjl@gnu-6 pr15167]$ cat unique_shared2.s .data .dc.ab [hjl@gnu-6 pr15167]$ make as -o unique_shared1.o unique_shared1.s as -o unique_shared2.o unique_shared2.s ./ld -shared -o unique_shared.so unique_shared1.o unique_shared2.o readelf -s unique_shared.so | grep UNIQ make: *** [all] Error 1 [hjl@gnu-6 pr15167]$ -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15167] ld merges gnu_unique def and normal ref into normal symbol
http://sourceware.org/bugzilla/show_bug.cgi?id=15167 Stephan Bergmann changed: What|Removed |Added CC||sbergman at redhat dot com -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15167] New: ld merges gnu_unique def and normal ref into normal symbol
http://sourceware.org/bugzilla/show_bug.cgi?id=15167
Bug #: 15167
Summary: ld merges gnu_unique def and normal ref into normal
symbol
Product: binutils
Version: 2.24 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: m...@suse.de
Classification: Unclassified
This came up over at http://gcc.gnu.org/ml/gcc/2013-02/msg00227.html
describing a strange mismatch between two symbols that are unique, but
in the shared object one is normal and the other is unique. I traced
this back to an ordering problem in ld at
http://gcc.gnu.org/ml/gcc/2013-02/msg00239.html . The binutils involved
there are 2.21.1, but current upstream still exhibits the issue. I made a
minimal testcase with two asm files:
% cat unique1.s
.file "unique.cc"
.weak _ZN1SIiE1iE
.section.bss._ZN1SIiE1iE,"awG",@nobits,_ZN1SIiE1iE,comdat
.align 4
.type _ZN1SIiE1iE, @gnu_unique_object
.size _ZN1SIiE1iE, 4
_ZN1SIiE1iE:
.zero 4
.ident "GCC: (GNU) 4.6.1 20110505 (prerelease)"
.section.note.GNU-stack,"",@progbits
% cat unique2.s
.file "unique.cc"
.text
.align 2
.globl _ZN1SIiE3getEv
.type _ZN1SIiE3getEv, @function
_ZN1SIiE3getEv:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movq%rdi, -8(%rbp)
movq_ZN1SIiE1iE@GOTPCREL(%rip), %rax
movl(%rax), %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size _ZN1SIiE3getEv, .-_ZN1SIiE3getEv
.ident "GCC: (GNU) 4.6.1 20110505 (prerelease)"
.section.note.GNU-stack,"",@progbits
% gcc -c unique1.s unique2.s
% ./ld/ld-new -shared -o unique-ok.so unique2.o unique1.o
% ./ld/ld-new -shared -o unique-bad.so unique1.o unique2.o
% nm -D unique-bad.so | grep _ZN1SIiE1iE
00200398 B _ZN1SIiE1iE
% nm -D unique-ok.so | grep _ZN1SIiE1iE
00200398 u _ZN1SIiE1iE
In difference is that for unique-ok.so the reference to _ZN1SIiE1iE comes
first (in unique2.o), then the definition (in unique1.o), and that results
correctly in a global unique symbol exported from the DSO.
For unique-bad.so the definition comes first, and the uniqueness seems to
get lost when the normal reference is seen, so a normal global (not even weak)
symbol is now exported from the DSO.
This can (and as the thread at gcc@ shows actually does) lead to problems
when the system relies on some symbols to be indeed globally unique.
The empty_rep static member of libstdc++'s string<> and wstring<> templates
is one example.
As said, this is broken in at least 2.21.1 and in current trunk. FWIW,
the C++ source I used to initially generate the above asms is:
template
struct S {
static T i;
T get();
};
template T S::i;
template <> int S::get() { return i; }
compiled with -fPIC, and then split the .s into two by hand.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
