[Bug gold/18855] New: String constants mixed up when linked with gold on Linux/sparc64
https://sourceware.org/bugzilla/show_bug.cgi?id=18855 Bug ID: 18855 Summary: String constants mixed up when linked with gold on Linux/sparc64 Product: binutils Version: 2.26 (HEAD) Status: NEW Severity: critical Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: atar4qemu at gmail dot com CC: ian at airs dot com Target Milestone: --- Created attachment 8538 --> https://sourceware.org/bugzilla/attachment.cgi?id=8538&action=edit gcc -v -Wl,--verbose log with -Wl,-fuse-ld=gold Systemd components linked with gold fail under sparc(64). I can't reproduce the bug with a smaller test case, but it's 100% reproducible with building systemd: # First, try linking with bfd: $ gcc -pipe -Wall -Wextra -Wundef -Wformat=2 -Wformat-security -Wformat-nonliteral -Wlogical-op -Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wsuggest-attribute=noreturn -Werror=missing-prototypes -Werror=implicit-function-declaration -Werror=missing-declarations -Werror=return-type -Werror=shadow -Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wno-format-signedness -Werror=overflow -Wdate-time -Wnested-externs -ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing -fvisibility=hidden -fstack-protector -fstack-protector-strong -fPIE --param=ssp-buffer-size=4 -flto -ffunction-sections -fdata-sections -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wl,--gc-sections -Wl,--as-needed -Wl,--no-undefined -Wl,-z -Wl,relro -Wl,-z -Wl,now -pie -Wl,-fuse-ld=bfd -Wl,-z -Wl,relro -o udevadm src/udev/udevadm.o src/udev/udevadm-info.o src/udev/udevadm-control.o src/udev/udevadm-monitor.o src/udev/udevadm-hwdb.o src/udev/udevadm-settle.o src/udev/udevadm-trigger.o src/udev/udevadm-test.o src/udev/udevadm-test-builtin.o src/udev/udevadm-util.o ./.libs/libudev-core.a -lselinux -ldl -lrt -lm -lresolv -llzma -lgcrypt -lacl -lblkid -lkmod -lcap -pthread -v -Wl,--verbose -v > ../bfd.log 2>&1 # Save the binary mv udevadm udevadm-bfd # Link with gold gcc -pipe -Wall -Wextra -Wundef -Wformat=2 -Wformat-security -Wformat-nonliteral -Wlogical-op -Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wsuggest-attribute=noreturn -Werror=missing-prototypes -Werror=implicit-function-declaration -Werror=missing-declarations -Werror=return-type -Werror=shadow -Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wno-format-signedness -Werror=overflow -Wdate-time -Wnested-externs -ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing -fvisibility=hidden -fstack-protector -fstack-protector-strong -fPIE --param=ssp-buffer-size=4 -flto -ffunction-sections -fdata-sections -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wl,--gc-sections -Wl,--as-needed -Wl,--no-undefined -Wl,-z -Wl,relro -Wl,-z -Wl,now -pie -Wl,-fuse-ld=gold -Wl,-z -Wl,relro -o udevadm src/udev/udevadm.o src/udev/udevadm-info.o src/udev/udevadm-control.o src/udev/udevadm-monitor.o src/udev/udevadm-hwdb.o src/udev/udevadm-settle.o src/udev/udevadm-trigger.o src/udev/udevadm-test.o src/udev/udevadm-test-builtin.o src/udev/udevadm-util.o ./.libs/libudev-core.a -lselinux -ldl -lrt -lm -lresolv -llzma -lgcrypt -lacl -lblkid -lkmod -lcap -pthread -v -Wl,--verbose -v > ../gold.log 2>&1 # Now try the binaries: $ ./udevadm-bfd --version 224 $ ./udevadm --version %-6s[%li.%06ld] %-8s %s (%s) As you see the binary linked with gold takes a wrong string for the version. Some other strings are mixed up as well. ( Debian Bug#790560 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790560 ) At least the binutils versions 2.24, 2.25, 2.25.1 and HEAD are affected. -- 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 gold/18846] gold PowerPC --emit-relocs differ from ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18846 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9215b98bb27c071386a277f5578dbb17569a1471 commit 9215b98bb27c071386a277f5578dbb17569a1471 Author: Alan Modra Date: Thu Aug 20 12:02:45 2015 +0930 gold --emit-relocs A symbol value in an ELF final linked binary is absolute, in contrast to a relocatable object file where the value is section relative. For --emit-relocs it is therefore incorrect to use the value of a section symbol as the addend when adjusting relocs against input section symbols to output section symbols. PR gold/18846 * target-reloc.h (relocate_relocs ): Subtract os->address() from addend. * powerpc.cc (relocate_relocs): Likewise. -- 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 gold/18845] Using emit-relocs and icf ends in assert fail.
https://sourceware.org/bugzilla/show_bug.cgi?id=18845 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- IBMs FDPR tool http://www.haifa.ibm.com/projects/systems/cot/fdpr/ uses --emit-relocs. Which is why powerpc is probably the only target to fuss over emitting relocs that make sense on edited code, eg. we translate tls relocs as well as tls code sequences. -- 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 gold/18859] New: Gold linker does not fully respect -no-as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=18859
Bug ID: 18859
Summary: Gold linker does not fully respect -no-as-needed
Product: binutils
Version: 2.26 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: eugeni.stepanov at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Gold and ld behave differently when a shared library is first mentioned when
-as-needed is in effect, and then again after -no-as-needed. Ld generates a
DT_NEEDED entry for such library, and gold does not.
$ cat 1.c
int main() { return 0; }
# BFD linker
$ g++ 1.c -Wl,-as-needed -lutil -Wl,-no-as-needed -lutil -fuse-ld=bfd &&
readelf -d a.out | grep NEEDED
0x0001 (NEEDED) Shared library: [libutil.so.1]
0x0001 (NEEDED) Shared library: [libstdc++.so.6]
0x0001 (NEEDED) Shared library: [libm.so.6]
0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0001 (NEEDED) Shared library: [libc.so.6]
# Gold linker
$ g++ 1.c -Wl,-as-needed -lutil -Wl,-no-as-needed -lutil -fuse-ld=gold &&
readelf -d a.out | grep NEEDED
0x0001 (NEEDED) Shared library: [libstdc++.so.6]
0x0001 (NEEDED) Shared library: [libm.so.6]
0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0001 (NEEDED) Shared library: [libc.so.6]
--
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 binutils/18276] AArch64: readelf, gas do not support TLSLD relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=18276 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Jiong Wang : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6ffe9a1ba36f3a896ae323e35a207b6451e8f7f9 commit 6ffe9a1ba36f3a896ae323e35a207b6451e8f7f9 Author: Jiong Wang Date: Wed Aug 19 11:18:25 2015 +0100 [AArch64][4/6] LD support TLSLD move/add relocation types 2015-08-19 Jiong Wang bfd/ PR ld/18276 * elfnn-aarch64.c (IS_AARCH64_TLS_RELOC): Recognize new relocation types, including BFD_RELOC_AARCH64_TLSLD_ADD_DTPREL_HI12, BFD_RELOC_AARCH64_TLSLD_MOVW_DTPREL_G0, BFD_RELOC_AARCH64_TLSLD_MOVW_DTPREL_G0_NC, BFD_RELOC_AARCH64_TLSLD_MOVW_DTPREL_G1, BFD_RELOC_AARCH64_TLSLD_MOVW_DTPREL_G1_NC, BFD_RELOC_AARCH64_TLSLD_MOVW_DTPREL_G2. (elfNN_aarch64_final_link_relocate): Likewise. * elfxx-aarch64.c (_bfd_aarch64_elf_put_addend): Likewise. (_bfd_aarch64_elf_resolve_relocation): Likewise. ld/testsuite/ * ld-aarch64/emit-relocs-87.s: New testcase. * ld-aarch64/emit-relocs-88.s: Likewise. * ld-aarch64/emit-relocs-88-overflow.s: Likewise. * ld-aarch64/emit-relocs-89.s: Likewise. * ld-aarch64/emit-relocs-90.s: Likewise. * ld-aarch64/emit-relocs-90-overflow.s: Likewise. * ld-aarch64/emit-relocs-523.s: Likewise. * ld-aarch64/emit-relocs-524.s: Likewise. * ld-aarch64/emit-relocs-525.s: Likewise. * ld-aarch64/emit-relocs-527.s: Likewise. * ld-aarch64/emit-relocs-526.s: Likewise. * ld-aarch64/emit-relocs-528.s: Likewise. * ld-aarch64/emit-relocs-528-overflow.s: Likewise. * ld-aarch64/emit-relocs-87.d: New expectation file. * ld-aarch64/emit-relocs-88.d: Likewise. * ld-aarch64/emit-relocs-88-overflow.d: Likewise. * ld-aarch64/emit-relocs-89.d: Likewise. * ld-aarch64/emit-relocs-90.d: Likewise. * ld-aarch64/emit-relocs-90-overflow.d: Likewise. * ld-aarch64/emit-relocs-91.d: Likewise. * ld-aarch64/emit-relocs-523.d: Likewise. * ld-aarch64/emit-relocs-524.d: Likewise. * ld-aarch64/emit-relocs-525.d: Likewise. * ld-aarch64/emit-relocs-526.d: Likewise. * ld-aarch64/emit-relocs-527.d: Likewise. * ld-aarch64/emit-relocs-528.d: Likewise. * ld-aarch64/emit-relocs-528-overflow.d: Likewise. * ld-aarch64/aarch64-elf.exp: Run new testcases. -- 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 gold/18859] Gold linker does not fully respect -no-as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=18859 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Cary Coutant --- > Gold and ld behave differently when a shared library is first mentioned when > -as-needed is in effect, and then again after -no-as-needed. Ld generates a > DT_NEEDED entry for such library, and gold does not. Why are you expecting a NEEDED entry for libutil? There's nothing in your main program that depends on anything in that library, so by the definition of the --as-needed option, gold is doing exactly what I would expect. Your command line lists "-lutil" twice, once between the as-needed options, and once after. Gold ignores any shared library listed on the command line that it has already processed. If you want the library in your DT_NEEDED list, remove the first copy from your command line (the one between --as-needed and --no-as-needed). -- 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 gold/18855] String constants mixed up when linked with gold on Linux/sparc64
https://sourceware.org/bugzilla/show_bug.cgi?id=18855 --- Comment #1 from Cary Coutant --- Sorry, I don't have a SPARC development environment, so to investigate this, I'm going to need all the .o files (real .o files, not LTO intermediates). Does it still fail without -flto? Can you add -Wl,--stats to the command line and attach the output? -- 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 gold/18859] Gold linker does not fully respect -no-as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=18859 --- Comment #2 from Evgeniy Stepanov --- There is some context here: https://llvm.org/bugs/show_bug.cgi?id=15823 In the clang driver, we add a static library that implements wrappers for libutil functions, i.e. it exports functions with the same names and calls the real libutil functions with dlsym(RTLD_NEXT). To ensure that the executable still depends on libutil, we add -no-as-needed -lutil to the end of the link line - otherwise the linker thinks that all libutil dependencies are already satisfied by the wrapper library. The first "-as-needed -lutil" comes from the clang command line. -- 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 gold/14746] ld: internal error in address, at gold/output.h:72 while building Linux kvm tool
https://sourceware.org/bugzilla/show_bug.cgi?id=14746
--- Comment #8 from Cary Coutant ---
> What I had to do to reproduce it was to add a symbol in my linker script
> that pointed to the address of .eh_frame. It's the same assert but I'm not
> sure that it's the same problem.
>
> Repo:
> test.c
> main(){ return 0; }
>
> g++ -c -o test.o test.c
>
> test.o need to contain an eh_frame.
>
> ld.gold -T script.lcf test.o
> ld.gold: internal error in address, at ../../gold/output.h:73
This is a different problem. In the original case, gold was trying to allocate
something in a discarded section. I don't expect that case to work, but it does
need a better diagnostic.
In this case, the .eh_frame section isn't discarded, but we're trying to get
its address before it's been computed (since .eh_frame is a linker-optimized
section, it hasn't been finalized yet). This case really ought to work.
--
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 gold/14754] referring to undefined symbol results in internal error instead of helpful error message
https://sourceware.org/bugzilla/show_bug.cgi?id=14754 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|ccoutant at gmail dot com -- 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 gold/14746] ld: internal error in address, at gold/output.h:72 while building Linux kvm tool
https://sourceware.org/bugzilla/show_bug.cgi?id=14746
Johan Karlsson changed:
What|Removed |Added
CC||johan.karlsson at enea dot com
--- Comment #7 from Johan Karlsson ---
Created attachment 8537
--> https://sourceware.org/bugzilla/attachment.cgi?id=8537&action=edit
Linker script repo
I think I'm able to reproduce this issue.
What I had to do to reproduce it was to add a symbol in my linker script that
pointed to the address of .eh_frame. It's the same assert but I'm not sure that
it's the same problem.
Repo:
test.c
main(){ return 0; }
g++ -c -o test.o test.c
test.o need to contain an eh_frame.
ld.gold -T script.lcf test.o
ld.gold: internal error in address, at ../../gold/output.h:73
--
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/18860] New: Order of ELF symbols is not preserved
https://sourceware.org/bugzilla/show_bug.cgi?id=18860
Bug ID: 18860
Summary: Order of ELF symbols is not preserved
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: dje at google dot com
Target Milestone: ---
Demangling of ELF symbols is broken in gdb, and probably not fixable (in the
general case). The problem is "What language does one demangle the symbol in?"
There is no standard, nor likely to ever be one. To make things worse GNU C++
and Java share the same demangling scheme.
One possibility to solve this is to use the language encoded in the DWARF and
use that to decide how to demangle ELF symbols in that CU. It's a bit
unfortunate to require DWARF in order to properly interpret ELF.
One heuristic gdb employs is to look at the last file symbol and assume all
symbols for that file immediately follow it, and then choose the language based
on the source file name. That no longer works (not sure it ever worked for ELF)
because the linker bunches all the file symbols together (I'm not sure if it's
sorting them somehow or what). And of course this is just a heuristic, but not
a bad one.
Arguably this isn't a linker bug, I'm not aware of a spec that says the linker
has to retain symbol order in the way gdb expects it to.
The purpose of this bug report is to document the problem,
and see if it's possible to make the linker behave the way gdb expects it to.
The linker has been working this way a long time (forever?) - I couldn't find
an existing bug - I'm guessing this isn't news to anyone, but IWBN to document
why things are the way they are and establish closure (e.g., so we can remove
this hack from gdb since it's useless and can lead to confusion in the
debugging session).
Repro:
@ruffy2:play$ cat elf-file-name.cc
extern "C" int foo ();
extern int bar ();
int
main ()
{
return foo () + bar ();
}
@ruffy2:play$ cat elf-file-name-1.c
int
foo (void)
{
return 0;
}
@ruffy2:play$ cat elf-file-name-2.cc
int
bar ()
{
return 0;
}
@ruffy2:play$ gcc -c -g elf*.c elf*.cc
@ruffy2:play$ g++ elf*.o
@ruffy2:play$ readelf -s a.out
-->
...
39: 004004c0 0 FUNCLOCAL DEFAULT 13 frame_dummy
40: 00600e10 0 OBJECT LOCAL DEFAULT 18
__frame_dummy_init_array_
41: 0 FILELOCAL DEFAULT ABS elf-file-name-1.c
42: 0 FILELOCAL DEFAULT ABS elf-file-name-2.cc
43: 0 FILELOCAL DEFAULT ABS elf-file-name.cc
44: 0 FILELOCAL DEFAULT ABS crtstuff.c
45: 00400728 0 OBJECT LOCAL DEFAULT 17 __FRAME_END__
46: 00600e20 0 OBJECT LOCAL DEFAULT 20 __JCR_END__
...
--
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/18860] Order of ELF symbols is not preserved
https://sourceware.org/bugzilla/show_bug.cgi?id=18860 --- Comment #1 from dje at google dot com --- Of course, having written this, I can't find the place in gdb that uses this heuristic. Memory fail? -- 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 gold/18846] gold PowerPC --emit-relocs differ from ld
https://sourceware.org/bugzilla/show_bug.cgi?id=18846 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.26 --- Comment #3 from Alan Modra --- Fixed. -- 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 binutils/18276] AArch64: readelf, gas do not support TLSLD relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=18276 Jiong Wang changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jiong Wang --- mark as fixed -- 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/18860] Order of ELF symbols is not preserved
https://sourceware.org/bugzilla/show_bug.cgi?id=18860 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Alan Modra --- Note that the ELF spec requires local symbols to be output before global symbols. You can't infer anything about a global symbol from file symbols. -- 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
