[Bug gold/23258] Linker cored dump at process_one_opcode
https://sourceware.org/bugzilla/show_bug.cgi?id=23258 --- Comment #3 from Cary Coutant --- I can't extract anything from the .tar file you provided -- tar tv and tar xv just hang indefinitely. -- 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/23411] New: Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411
Bug ID: 23411
Summary: Different behavior when linking common symbol
statically or to shared object
Product: binutils
Version: 2.32 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: hjl.tools at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
[hjl@gnu-cfl-1 gold-2]$ cat con.c
int globalInt = 7;
[hjl@gnu-cfl-1 gold-2]$ cat main.c
#include
int globalInt;
int main()
{
printf("globalInt is %d\n", globalInt);
return 0;
}
[hjl@gnu-cfl-1 gold-2]$ make
gcc -fuse-ld=gold -fpic -c -o main.o main.c
gcc -fuse-ld=gold -fpic -c -o con.o con.c
gcc -fuse-ld=gold -shared -fpic -o libcon.so con.o
gcc -fuse-ld=gold -o app.shared main.o -L. -lcon -Wl,-R,.
gcc -fuse-ld=gold -o app.static main.o con.o
ar rv libcon.a con.o
r - con.o
gcc -fuse-ld=gold -o app.a main.o libcon.a
./app.shared
globalInt is 0
./app.static
globalInt is 7
./app.a
globalInt is 0
[hjl@gnu-cfl-1 gold-2]$ make clean
rm -f *.o libcon.so app.shared app.static
[hjl@gnu-cfl-1 gold-2]$ make CC=gcc
gcc -fpic -c -o main.o main.c
gcc -fpic -c -o con.o con.c
gcc -shared -fpic -o libcon.so con.o
gcc -o app.shared main.o -L. -lcon -Wl,-R,.
gcc -o app.static main.o con.o
ar rv libcon.a con.o
r - con.o
gcc -o app.a main.o libcon.a
./app.shared
globalInt is 7
./app.static
globalInt is 7
./app.a
globalInt is 7
[hjl@gnu-cfl-1 gold-2]$
--
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/22755] gold test suite failures (gentoo, 2.31)
https://sourceware.org/bugzilla/show_bug.cgi?id=22755 --- Comment #4 from Cary Coutant --- Well, that didn't help -- nothing in config.log helps me reproduce these failures. I'll need some more of your help. Let's start with the first one; with luck, there's just one thing going on that's causing all of these failures. > FAIL: strong_ref_weak_def.sh > > > pattern ".* FUNC.* GLOBAL.* UND.* weak_def" not found in file > strong_ref_weak_def.stdout. > > FAIL strong_ref_weak_def.sh (exit status: 1) Try this: $ cd .../gold/testsuite $ rm strong_ref_weak_def* $ make strong_ref_weak_def.stdout That should run some commands like these: `echo gcc -DHAVE_CONFIG_H -I. -I../../../binutils-gdb/gold/testsuite -I.. -I../../../binutils-gdb/gold/testsuite -I../../../binutils-gdb/gold/testsuite/.. -I../../../binutils-gdb/gold/testsuite/../../include -I../../../binutils-gdb/gold/testsuite/../../elfcpp -I.. -DLOCALEDIR="\"/usr/local/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -g -O0 | sed -e 's/-Wp,-D_FORTIFY_SOURCE=[0-9[0-9]]*//'` -o strong_ref_weak_def_1.o -c -fPIC ../../../binutils-gdb/gold/testsuite/strong_ref_weak_def_1.c `echo gcc -DHAVE_CONFIG_H -I. -I../../../binutils-gdb/gold/testsuite -I.. -I../../../binutils-gdb/gold/testsuite -I../../../binutils-gdb/gold/testsuite/.. -I../../../binutils-gdb/gold/testsuite/../../include -I../../../binutils-gdb/gold/testsuite/../../elfcpp -I.. -DLOCALEDIR="\"/usr/local/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fmerge-constants -g -O0 | sed -e 's/-Wp,-D_FORTIFY_SOURCE=[0-9[0-9]]*//'` -o strong_ref_weak_def_2.o -c -fPIC ../../../binutils-gdb/gold/testsuite/strong_ref_weak_def_2.c gcctestdir/ld -shared -o strong_ref_weak_def_2.so strong_ref_weak_def_2.o gcctestdir/ld -shared -o strong_ref_weak_def_1.so strong_ref_weak_def_1.o \ strong_ref_weak_def_2.so ../../binutils/readelf -sWD strong_ref_weak_def_1.so > strong_ref_weak_def.stdout Now re-run those two gcc commands manually, but add a -v option, and send me the output. Also attach strong_ref_weak_def_[12].o and strong_ref_weak_def.stdout. -- 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/23258] Linker cored dump at process_one_opcode
https://sourceware.org/bugzilla/show_bug.cgi?id=23258 --- Comment #4 from Lan --- hmm ... worked just fine for me. lans-mbp:downloads lanpham$ tar -xvf bug_23258.tar x bug_23258/libSTdb2gse.a x bug_23258/lnk.sh lans-mbp:downloads lanpham$ -- 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
Re: [Bug gold/23258] Linker cored dump at process_one_opcode
Got it now -- sorry, problem on my end. On Fri, Jul 13, 2018 at 11:14 AM, lpham54321 at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=23258 > > --- Comment #4 from Lan --- > hmm ... worked just fine for me. > > lans-mbp:downloads lanpham$ tar -xvf bug_23258.tar > x bug_23258/libSTdb2gse.a > x bug_23258/lnk.sh > lans-mbp:downloads lanpham$ > > -- > 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23258] Linker cored dump at process_one_opcode
https://sourceware.org/bugzilla/show_bug.cgi?id=23258 --- Comment #5 from Cary Coutant --- Got it now -- sorry, problem on my end. On Fri, Jul 13, 2018 at 11:14 AM, lpham54321 at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=23258 > > --- Comment #4 from Lan --- > hmm ... worked just fine for me. > > lans-mbp:downloads lanpham$ tar -xvf bug_23258.tar > x bug_23258/libSTdb2gse.a > x bug_23258/lnk.sh > lans-mbp:downloads lanpham$ > > -- > 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 -- 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/23258] Linker cored dump at process_one_opcode
https://sourceware.org/bugzilla/show_bug.cgi?id=23258 --- Comment #6 from Cary Coutant --- I don't have clang installed, but when I use g++ instead, I get the following: GseAdEnableDB.o: In function `GseAdmTempFile(char*, char const*, char const*, GseError&)': /db2src/spatial/admin/GseAdEnableDB.SQC:187: warning: the use of `tempnam' is dangerous, better use `mkstemp' Is this the warning message that's triggering the crash on your end? From the stack trace you provided, it seems likely. It's processing the debug info just fine for me. -- 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/23258] Linker cored dump at process_one_opcode
https://sourceware.org/bugzilla/show_bug.cgi?id=23258 --- Comment #7 from Lan --- It's the loader that trapped, but it was clang6 that was generating the object file. Can you try just invoking the loader directly against the static archive libSTdb2gse.a to see if you can repro the trap? /usr/bin/ld --hash-style=gnu --no-add-needed --eh-frame-hdr -m elf_x86_64 -shared -o db2gse /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtbeginS.o -L. -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64 -L/usr/local/bin/../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../.. -L/usr/local/bin/../lib -L/lib -L/usr/lib -soname db2gse --whole-archive libSTdb2gse.a --no-whole-archive --enable-new-dtags --enable-new-dtags -lpthread -lm -lstdc++ -lm -lgcc_s -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crtn.o It's likely that clang 6 generated something that is incompatible with the loader. -- 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
Re: [Bug gold/23258] Linker cored dump at process_one_opcode
I was just using g++ as the linker driver, not to compile the objects. I linked with the objects you provided, which had been compiled by clang. Linking just those objects by themselves produces no warnings at all, since the "tempnam" warning comes from libc. On Fri, Jul 13, 2018 at 12:05 PM, lpham54321 at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=23258 > > --- Comment #7 from Lan --- > It's the loader that trapped, but it was clang6 that was generating the object > file. > > Can you try just invoking the loader directly against the static archive > libSTdb2gse.a to see if you can repro the trap? > > /usr/bin/ld --hash-style=gnu --no-add-needed --eh-frame-hdr -m elf_x86_64 > -shared -o db2gse > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crti.o > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtbeginS.o -L. > -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5 > -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64 > -L/usr/local/bin/../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 > -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../.. -L/usr/local/bin/../lib > -L/lib -L/usr/lib -soname db2gse --whole-archive libSTdb2gse.a > --no-whole-archive --enable-new-dtags --enable-new-dtags -lpthread -lm > -lstdc++ > -lm -lgcc_s -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtendS.o > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crtn.o > > It's likely that clang 6 generated something that is incompatible with the > loader. > > -- > 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 mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23258] Linker cored dump at process_one_opcode
https://sourceware.org/bugzilla/show_bug.cgi?id=23258 --- Comment #8 from Cary Coutant --- I was just using g++ as the linker driver, not to compile the objects. I linked with the objects you provided, which had been compiled by clang. Linking just those objects by themselves produces no warnings at all, since the "tempnam" warning comes from libc. On Fri, Jul 13, 2018 at 12:05 PM, lpham54321 at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=23258 > > --- Comment #7 from Lan --- > It's the loader that trapped, but it was clang6 that was generating the object > file. > > Can you try just invoking the loader directly against the static archive > libSTdb2gse.a to see if you can repro the trap? > > /usr/bin/ld --hash-style=gnu --no-add-needed --eh-frame-hdr -m elf_x86_64 > -shared -o db2gse > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crti.o > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtbeginS.o -L. > -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5 > -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64 > -L/usr/local/bin/../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 > -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../.. -L/usr/local/bin/../lib > -L/lib -L/usr/lib -soname db2gse --whole-archive libSTdb2gse.a > --no-whole-archive --enable-new-dtags --enable-new-dtags -lpthread -lm > -lstdc++ > -lm -lgcc_s -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtendS.o > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crtn.o > > It's likely that clang 6 generated something that is incompatible with the > loader. > > -- > 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 -- 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/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 Alexander Monakov changed: What|Removed |Added CC||amonakov at gmail dot com --- Comment #1 from Alexander Monakov --- I think the behavior exhibited by gold is expected given absence of --whole-archive, and it's ld.bfd that is doing something not mandated by the ELF spec here. -- 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/23258] Linker cored dump at process_one_opcode
https://sourceware.org/bugzilla/show_bug.cgi?id=23258 --- Comment #9 from Lan --- ok. I assume that you want me to try addressing the warning to see if it is indeed related to the core dump. I will try this and let you know how it's go. -- 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/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Cary Coutant --- For ANSI/ISO C and C++, gold is doing the right thing here. Time for a history lesson... In the old days of K&R C, a declaration like "int globalInt;" was considered a "tentative definition", and was implemented using the same linker mechanism as a Fortran common block (hence, the name "common"). Linkers in the K&R era had the following rules with respect to linking from archive libraries: - undef in .o, common in archive member: upgrade the undef to a common, but do not include the archive member (unless it also provides another needed symbol definition). - common in .o, common in archive member: don't include the archive member. - common in .o, regular def in archive member: include the archive member. By those rules, yes, the linker would have included con.o from the archive, and you'd see the value 7. When ANSI C came along, the notion of "tentative definition" was dropped from the language. A declaration "int globalInt;" was considered the same as "int globalInt = 0;", with one exception -- in a nod to compatibility with existing source code, compilers were permitted to allow multiple definitions of the old tentative form, but were supposed to diagnose multiple definitions that did not agree, so your static linking example (main.o + con.o) should give an error. This required a slight change in the rules of linking: - undef in .o, common in archive member: include the archive member. - common in .o, common in archive member: don't include the archive member. - common in .o, regular def in archive member: don't include the archive member. Gold implements these rules. Some compilers chose to implement "int globalInt;" as a regular definition, and kept the use of common for K&R C only. At HP, we added a new SHN_HP_ANSI_COMMON so that we could distinguish between the two cases. Others simply continued to generate common symbols as always (technically in violation of the language standard). If you change main.c to say "int globalInt = 0;", ld.bfd and gold will both give the same results as gold does in your example, except that the static case (main.o + con.o) will produce a multiple definition error (as it should). According to the language standard, the results should be the same with or without the "= 0". -- 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/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 --- Comment #3 from H.J. Lu --- We can agree to disagree. I believe the new rule should be enforced by compiler not to generate COMMON symbol, not by linker. -- 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 gas/23412] New: .intel_syntax noprefix vs -msyntax=intel -mnaked-reg segment override inconsistency
https://sourceware.org/bugzilla/show_bug.cgi?id=23412 Bug ID: 23412 Summary: .intel_syntax noprefix vs -msyntax=intel -mnaked-reg segment override inconsistency Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jesse at eclypsium dot com Target Milestone: --- When using -msyntax=intel, as incorrectly parses instructions using segment overrides. # objdump -D -b binary -m i386 -M x86-64 -M intel test.bin test.bin: file format binary Disassembly of section .data: <.data>: 0: 2e 48 8b 04 25 44 33movrax,QWORD PTR cs:0x11223344 7: 22 11 If I try to assemble this instruction using -msyntax=intel -mnaked-reg command line arguments, as parses this instruction incorrectly and I can't find a variation that it will accept. # cat test-cmd-args.s mov rax, QWORD PTR cs:0x11223344 mov rax, cs:0x11223344 mov rax, cs:[0x11223344] mov rax, [cs:0x11223344] # as -msyntax=intel -mnaked-reg test-cmd-args.s test-cmd-args.s: Assembler messages: test-cmd-args.s:1: Error: invalid use of register test-cmd-args.s:2: Error: junk `:0x11223344' after expression test-cmd-args.s:3: Error: junk `:[0x11223344]' after expression test-cmd-args.s:4: Error: bad expression test-cmd-args.s:4: Error: junk `cs:0x11223344]' after expression However, if I use ".intel_syntax noprefix" in the source file, all variations are assembled correctly. # cat test-inline.s .intel_syntax noprefix mov rax, QWORD PTR cs:0x11223344 mov rax, cs:0x11223344 mov rax, cs:[0x11223344] mov rax, [cs:0x11223344] # as -msyntax=intel -mnaked-reg test-inline.s # objdump -d a.out a.out: file format elf64-x86-64 Disassembly of section .text: <.text>: 0: 2e 48 8b 04 25 44 33mov%cs:0x11223344,%rax 7: 22 11 9: 2e 48 8b 04 25 44 33mov%cs:0x11223344,%rax 10: 22 11 12: 2e 48 8b 04 25 44 33mov%cs:0x11223344,%rax 19: 22 11 1b: 2e 48 8b 04 25 44 33mov%cs:0x11223344,%rax 22: 22 11 # as --version GNU assembler (GNU Binutils for Debian) 2.30 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux-gnu'. There does not appear to be a way to get as to correctly assemble these instructions without including ".intel_synax noprefix" in the source file. -- 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
