[Bug binutils/6006] thin archive support breaks existing archives
--- Additional Comments From ccoutant at google dot com 2008-03-31 21:18 --- When Nick reviewed my patch, he did some additional code cleanup and changed several instances of '\012' to ARFMAG[0]. That should have been ARFMAG[1]. -- What|Removed |Added Status|NEW |ASSIGNED http://sourceware.org/bugzilla/show_bug.cgi?id=6006 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6006] thin archive support breaks existing archives
-- What|Removed |Added AssignedTo|unassigned at sources dot |ccoutant at google dot com |redhat dot com | http://sourceware.org/bugzilla/show_bug.cgi?id=6006 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/13288] gold silently accepts truncated ELF input
http://sourceware.org/bugzilla/show_bug.cgi?id=13288 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Cary Coutant 2011-10-18 00:27:34 UTC --- Fixed in trunk. -- 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 gold/13023] gold misinterprets dot assignments in sections
http://sourceware.org/bugzilla/show_bug.cgi?id=13023 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED CC||ccoutant at google dot com AssignedTo|ian at airs dot com |ccoutant at google dot com --- Comment #4 from Cary Coutant 2011-10-28 21:31:47 UTC --- Proposed patch: http://sourceware.org/ml/binutils/2011-10/msg00293.html -- 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 gold/13359] gold internal error in relocate_tls, at gold/x86_64.cc:3187
http://sourceware.org/bugzilla/show_bug.cgi?id=13359 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|ian at airs dot com |ccoutant at google dot com --- Comment #1 from Cary Coutant 2011-10-28 22:48:37 UTC --- Proposed patch: http://sourceware.org/ml/binutils/2011-10/msg00294.html -- 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 gold/13359] gold internal error in relocate_tls, at gold/x86_64.cc:3187
http://sourceware.org/bugzilla/show_bug.cgi?id=13359 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Cary Coutant 2011-10-31 22:37:35 UTC --- Fixed on trunk. -- 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 gold/13023] gold misinterprets dot assignments in sections
http://sourceware.org/bugzilla/show_bug.cgi?id=13023 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Cary Coutant 2011-10-31 23:15:20 UTC --- Fixed in trunk. -- 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 gold/13597] Broken sysv-style hash table when --hash-style=both
http://sourceware.org/bugzilla/show_bug.cgi?id=13597 --- Comment #4 from Cary Coutant 2012-01-17 21:26:14 UTC --- I don't know of any reason why the section order would matter. Generating the .gnu.hash first sounds like the best fix to me. I'd suggest adding a comment that explains why the order matters, though. -cary -- 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 gold/13442] gold screws up exception handling with --incremental flag
http://sourceware.org/bugzilla/show_bug.cgi?id=13442 --- Comment #2 from Cary Coutant 2012-02-11 00:24:30 UTC --- Have you tried this with a recent linker? This should have been fixed with: http://sourceware.org/ml/binutils/2011-09/msg00113.html -- 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 gold/14007] Linker should try to validate the data that a plugin passes to it
http://sourceware.org/bugzilla/show_bug.cgi?id=14007 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|ian at airs dot com |ccoutant at google 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 gold/14149] The _end symbol is not properly aligned
http://sourceware.org/bugzilla/show_bug.cgi?id=14149 --- Comment #1 from Cary Coutant 2012-05-23 21:59:08 UTC --- > Note that _end has a mis-aligned address. This causes jemalloc (the malloc in > FreeBSD's libc) to corrupt it's internal RB trees as it assumes the start of > the heap is aligned on at least an even address. Using ld.bfd results in _end > being aligned on an 8-byte boundary. The linker scripts for ld.bfd for > FreeBSD > explicitly pad _end to an 8 byte boundary, so I assume it is a bug for the > gold > linker to not do this. Not that I'm arguing the linker shouldn't do this, but I can't find anything in the x86 ABI or the AMD64 ABI documents that guarantee _end should have any specific alignment. The AMD64 ABI supplement says nothing about _end, and the Intel386 Sys V ABI supplement says only this: extern _end; This symbol refers neither to a routine nor to a location with interesting contents. Instead, its address must correspond to the beginning of a program’s dynamic allocation area, called the heap. Typically, the heap begins immediately after the data segment of the program’s executable file. It seems to me that your malloc implementation is relying on a behavior of the GNU linker that is not guaranteed by the ABI. Even if we do change gold to match the GNU ld behavior, I'd still recommend that you change the implementation to rely only on the documented ABI. -cary -- 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 gold/14330] failure to link global hidden symbol
http://sourceware.org/bugzilla/show_bug.cgi?id=14330 --- Comment #5 from Cary Coutant 2012-07-09 16:27:34 UTC --- >> It looks like the symbol was discarded for some reason, and the error is >> occurring because it is hidden. My guess is that the error should be >> suppressed--you should only be getting the warning about "relocation refers >> to >> discarded section". That warning is most likely about debug info, though >> it's >> hard to know for sure. > > Thanks for the thoughts. I wonder, though -- since the relocation seems to be > coming from the use of the hidden symbol and not the definition, I don't see > how it could be related to debug info. But I'm also fairl ignorant about > these > things. This is a wild guess, but I think your asm code is getting placed in a random section depending on the other options. Try adding a ".text" statement in the function definition below: DFGOperations.cpp: asm ( ".globl getHostCallReturnValue\n" ".hidden getHostCallReturnValue\n" "getHostCallReturnValue:\n" "mov -40(%r13), %r13\n" "mov %r13, %rdi\n" "jmp getHostCallReturnValueWithExecState\n" ); -cary -- 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 gold/14330] failure to link global hidden symbol
http://sourceware.org/bugzilla/show_bug.cgi?id=14330 --- Comment #6 from Cary Coutant 2012-07-09 16:40:12 UTC --- > This is a wild guess, but I think your asm code is getting placed in a > random section depending on the other options. Try adding a ".text" > statement in the function definition below: To expand a bit on this, the "relocation refers to discarded section" error typically indicates that we discarded a COMDAT section that defined a symbol x, where the kept COMDAT section did not define x. Any references to x from outside the COMDAT group will then produce this error. If the definition for getHostCallReturnValue immediately follows a function that is defined in a normal .text section, everything will work fine. If you change your -D options such that it follows a different function that happens to be defined in a COMDAT section (e.g., an out-of-line inline produced because you're compiling with -g), your function will then get added to that same COMDAT section, and you will see a failure whenever the linker discards that section in favor of an earlier instance of the same COMDAT group. -cary -- 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 gold/14344] FAIL: gdb_index_test_[12].sh
http://sourceware.org/bugzilla/show_bug.cgi?id=14344 --- Comment #3 from Cary Coutant 2012-07-10 08:15:28 UTC --- > I think tests should accept both "const int" and "int const". The point of the test is to make sure that it's in the canonical form expected by GDB. For GCC 4.6, perhaps we should just treat this as an XFAIL, or maybe have a configure check to turn off the test. -cary -- 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 gold/14344] FAIL: gdb_index_test_[12].sh
http://sourceware.org/bugzilla/show_bug.cgi?id=14344 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|ian at airs dot com |ccoutant at google dot com --- Comment #7 from Cary Coutant 2012-07-19 00:30:59 UTC --- Added configure check to disable the gdb_index tests when not using a compiler known to produce reliable pubnames information. -- 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 gold/14533] large (88M) ICC compiled .obj files inside .a archive confuse / error the gold linker
http://sourceware.org/bugzilla/show_bug.cgi?id=14533 --- Comment #3 from Cary Coutant 2012-08-31 17:22:08 UTC --- Sounds to me like a large section table bug in ICC. I believe we've seen that before. -cary On Fri, Aug 31, 2012 at 10:14 AM, bsergean at gmail dot com wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=14533 > > --- Comment #2 from Benjamin Sergeant 2012-08-31 > 17:14:34 UTC --- > 1) If I strip the .obj file the error seems to go away. > > 2) Here's the error. > > /tmp/gold-dev/bin/ld: libsomething.a(AnObjectFile.o): invalid string offset > 25281974 >= 48 for section `.shstrtab' > /tmp/gold-dev/bin/ld: libsomething.a(AnObjectFile.o): invalid string offset 79 >>= 48 for section `(null)' > /tmp/gold-dev/bin/ld: libsomething.a(AnObjectFile.o): invalid string offset > 25281974 >= 48 for section `.shstrtab' > /tmp/gold-dev/bin/ld: libsomething.a(AnObjectFile.o): invalid string offset 79 >>= 48 for section `(null)' > libsomething.a: member libsomething.a(AnObjectFile.o) in archive is not an > object > ~ > What's funny is that I don't get that last error "is not an object" if I try > to > make a shared lib from just that object. > > So maybe there's something weird with how (1) we create the .a (ranlib) or > with > how gold parse the .a. > > Here's what readelf says about that symbol. > > ELF Header: > Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 > Class: ELF64 > Data: 2's complement, little endian > Version: 1 (current) > OS/ABI:UNIX - Linux > ABI Version: 0 > Type: REL (Relocatable file) > Machine: Advanced Micro Devices X86-64 > Version: 0x1 > Entry point address: 0x0 > Start of program headers: 0 (bytes into file) > Start of section headers: 85864776 (bytes into file) > Flags: 0x0 > Size of this header: 64 (bytes) > Size of program headers: 0 (bytes) > Number of program headers: 0 > Size of section headers: 64 (bytes) > Number of section headers: 0 (92838) > Section header string table index: 65535 (66722) > > > If I tries to make a shared lib from that object file, here's what I get > > /tmp$ /tmp/gold-dev/bin/ld.gold -shared -o /tmp/caca.so AnObjectFile.o |& head > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: section name section has > wrong type: 4 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: symbol table name section > has > wrong type: 4 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: bad section name offset for > section 1: 79 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: extended index for symbol > 70238 out of range: 92838 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: extended index for symbol > 70239 out of range: 92839 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: extended index for symbol > 70240 out of range: 92840 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: extended index for symbol > 70241 out of range: 92841 > > > How can I help further with troubleshooting that ? > Can I add some debugging option to the linker ? > Can I extract just a piece of that .obj file, or obfuscate it so I can > upload / attach it to Bugzilla ? > > Thanks !! > > ps: > I haven't done any serious benchmark yet on the impact of linking with gold > but > on a large lib that we have (330M), linking with gold was 2.5x faster (5s to > 2s), and we have many of those libs. > > -- > 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. -- 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 gold/14533] large (88M) ICC compiled .obj files inside .a archive confuse / error the gold linker
http://sourceware.org/bugzilla/show_bug.cgi?id=14533 --- Comment #4 from Benjamin Sergeant 2012-08-31 17:42:16 UTC --- Found that when I googled for "large section ICC bug" http://sourceware.org/bugzilla/show_bug.cgi?id=5900 --- Comment #5 from Cary Coutant 2012-08-31 17:42:52 UTC --- > Sounds to me like a large section table bug in ICC. I believe we've > seen that before. According to http://sourceware.org/bugzilla/show_bug.cgi?id=5900, ICC has always worked correctly with large section tables; the bug was in gas and binutils (we've also seen it in LLVM, but it's also been fixed). I guess I'd have to look at the .o file to see what's wrong with it. Is there any place you can put it where I can download it? -cary -- 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 gold/14533] large (88M) ICC compiled .obj files inside .a archive confuse / error the gold linker
http://sourceware.org/bugzilla/show_bug.cgi?id=14533 --- Comment #6 from Cary Coutant 2012-08-31 18:08:49 UTC --- > /tmp/gold-dev/bin/ld: libsomething.a(AnObjectFile.o): invalid string offset > 25281974 >= 48 for section `.shstrtab' > /tmp/gold-dev/bin/ld: libsomething.a(AnObjectFile.o): invalid string offset 79 >>= 48 for section `(null)' > /tmp/gold-dev/bin/ld: libsomething.a(AnObjectFile.o): invalid string offset > 25281974 >= 48 for section `.shstrtab' > /tmp/gold-dev/bin/ld: libsomething.a(AnObjectFile.o): invalid string offset 79 >>= 48 for section `(null)' > libsomething.a: member libsomething.a(AnObjectFile.o) in archive is not an > object These do not look like gold error messages. > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: section name section has > wrong type: 4 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: symbol table name section > has > wrong type: 4 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: bad section name offset for > section 1: 79 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: extended index for symbol > 70238 out of range: 92838 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: extended index for symbol > 70239 out of range: 92839 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: extended index for symbol > 70240 out of range: 92840 > /tmp/gold-dev/bin/ld.gold: error: AnObjectFile.o: extended index for symbol > 70241 out of range: 92841 These do look like gold error messages. I think you have a gnu ld at /tmp/gold-dev/bin/ld, and gold is at /tmp/gold-dev/bin/ld.gold. If you can run readelf -SW on your file, and extract lines that match "66722" and "STRTAB", I think we might be able to prove that this file exhibits the large section table bug. -cary -- 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 gold/14533] large (88M) ICC compiled .obj files inside .a archive confuse / error the gold linker
http://sourceware.org/bugzilla/show_bug.cgi?id=14533 --- Comment #7 from Cary Coutant 2012-08-31 18:18:30 UTC --- > If you can run readelf -SW on your file, and extract lines that match > "66722" and "STRTAB", I think we might be able to prove that this file > exhibits the large section table bug. Indeed. I received your .o file (thanks!), and, according to readelf: [66466] STRTAB 27e92d2 20ad55b 00 0 0 1 ... [66722] RELA 489b08d 30 18 G 1 33507 8 According to the file header, section 66722 is supposed to be .shstrtab, but section 66466 (66722 - 256) is the actual string table section. (Readelf cannot display the section names because .shstrtab isn't where it's supposed to be.) Everything above section 65280 (0xff00) is offset by 256. This file is definitely produced by a compiler that doesn't handle large section tables correctly. Gold actually has a heuristic in place to correct for known bad assemblers, but that only works if the .shstrtab section is near the end of the section table, which it is not in this case. -cary -- 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 gold/14536] Unnecessary GOT usages
http://sourceware.org/bugzilla/show_bug.cgi?id=14536
--- Comment #1 from Cary Coutant 2012-08-31
21:19:20 UTC ---
I think this is related to the discussion here:
http://sourceware.org/ml/binutils/2011-03/msg00220.html.
-cary
On Fri, Aug 31, 2012 at 2:11 PM, hjl.tools at gmail dot com
wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=14536
>
> Bug #: 14536
>Summary: Unnecessary GOT usages
>Product: binutils
>Version: 2.23 (HEAD)
> Status: NEW
> Severity: normal
> Priority: P2
> Component: gold
> AssignedTo: i...@airs.com
> ReportedBy: hjl.to...@gmail.com
> CC: ccout...@google.com
> Classification: Unclassified
>
>
> On Linux/x86, gold gives
> [hjl@gnu-6 symbolic-6]$ cat foo.S
> .text
> .globlfoo
> .typefoo, @function
> foo:
> ret
> .sizefoo, .-foo
> .globl_start
> .type_start, @function
> _start:
> #ifdef __x86_64__
> movqfoo@GOTPCREL(%rip), %rax
> #else
> movlfoo@GOT(%ecx), %eax
> #endif
> .size_start, .-_start
> [hjl@gnu-6 symbolic-6]$ cat foo.t
> {
> global:
> _start;
> local:
> *;
> };
> [hjl@gnu-6 symbolic-6]$ make
> gcc -m32-c -o foo.o foo.S
> ./ld -m elf_i386 -Bsymbolic -shared -o libfoo.so foo.o
> ./ld -m elf_i386 -pie -o pie foo.o
> ./ld -m elf_i386 -o static foo.o
> ./ld -m elf_i386 -shared -o shared foo.o --version-script foo.t
> objdump -dw libfoo.so
>
> libfoo.so: file format elf32-i386
>
>
> Disassembly of section .text:
>
> 016c :
> 16c:c3 ret
>
> 016d <_start>:
> 16d:8b 81 fc ff ff ffmov-0x4(%ecx),%eax
> objdump -dw pie
>
> pie: file format elf32-i386
>
>
> Disassembly of section .text:
>
> 0114 :
> 114:c3 ret
>
> 0115 <_start>:
> 115:8b 81 fc ff ff ffmov-0x4(%ecx),%eax
> objdump -dw static
>
> static: file format elf32-i386
>
>
> Disassembly of section .text:
>
> 08048074 :
> 8048074:c3 ret
>
> 08048075 <_start>:
> 8048075:8b 81 fc ff ff ffmov-0x4(%ecx),%eax
> objdump -dw shared
>
> shared: file format elf32-i386
>
>
> Disassembly of section .text:
>
> 00f8 :
> f8:c3 ret
>
> 00f9 <_start>:
> f9:8b 81 fc ff ff ffmov-0x4(%ecx),%eax
> readelf -SW libfoo.so | grep ".got " || true
> [ 7] .got PROGBITS1204 000204 04 00 WA 0 0
> 4
> readelf -SW pie | grep ".got " || true
> [ 8] .got PROGBITS11a4 0001a4 04 00 WA 0 0
> 4
> readelf -SW static | grep ".got " || true
> [ 2] .got PROGBITS0804907c 7c 04 00 WA 0 0
> 4
> readelf -SW shared | grep ".got " || true
> [ 7] .got PROGBITS1180 000180 04 00 WA 0 0
> 4
> [hjl@gnu-6 symbolic-6]$
>
> bfd linker gave
>
> [hjl@gnu-6 symbolic-6]$ make LD=./ld.bfd
> gcc -m32-c -o foo.o foo.S
> ./ld.bfd -m elf_i386 -Bsymbolic -shared -o libfoo.so foo.o
> ./ld.bfd -m elf_i386 -pie -o pie foo.o
> ./ld.bfd -m elf_i386 -o static foo.o
> ./ld.bfd -m elf_i386 -shared -o shared foo.o --version-script foo.t
> objdump -dw libfoo.so
>
> libfoo.so: file format elf32-i386
>
>
> Disassembly of section .text:
>
> 0140 :
> 140:c3 ret
>
> 0141 <_start>:
> 141:8d 81 98 ef ff fflea-0x1068(%ecx),%eax
> objdump -dw pie
>
> pie: file format elf32-i386
>
>
> Disassembly of section .text:
>
> 0168 :
> 168:c3 ret
>
> 0169 <_start>:
> 169:8d 81 98 ef ff fflea-0x1068(%ecx),%eax
> objdump -dw static
>
> static: file format elf32-i386
>
>
> Disassembly of section .text:
>
> 08048074 :
> 8048074:c3 ret
>
> 08048075 <_start>:
> 8048075:8d 81 f8 ef ff fflea-0x1008(%ecx),%eax
> objdump -dw shared
>
> shared: file format elf32-i386
>
>
> Disassembly of section .text:
>
> 00d0 :
> d0:c3 ret
>
> 00d1 <_start>:
> d1:8d 81 a0 ef ff fflea-0x1060(%ecx),%eax
> readelf -SW libfoo.so | grep ".got " || true
> readelf -SW pie | grep ".got " || true
> readelf -SW static | grep ".got " || true
> readelf -SW shared | grep ".got " || true
> [hjl@gnu-6 symbolic-6]$
>
> The same goes for Linux/x86-64.
>
> --
> 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.
--
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 gold/14608] --detect-odr-violations doesn't work with GCC 4.7
http://sourceware.org/bugzilla/show_bug.cgi?id=14608 Cary Coutant changed: What|Removed |Added AssignedTo|ian at airs dot com |ccoutant at google 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 gold/15021] Gold generated index difference from gdb: symbols from TUs reference the containing CU
http://sourceware.org/bugzilla/show_bug.cgi?id=15021 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX AssignedTo|ian at airs dot com |ccoutant at google dot com --- Comment #1 from Cary Coutant 2013-01-16 23:55:47 UTC --- This is expected because the GCC-generated pubnames table has no way for some entries to refer to a CU, and others to refer to separate TUs. The only way to make this work would be to have separate pubnames/pubtypes tables for each TU, which would be impractical. We will eventually fix this with better accelerator tables. -- 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 gold/15098] DT_RPATH isn't set with -rpath on Linux
http://sourceware.org/bugzilla/show_bug.cgi?id=15098 Cary Coutant changed: What|Removed |Added AssignedTo|ian at airs dot com |ccoutant at google 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 gold/15334] dwp utility has no documentation
http://sourceware.org/bugzilla/show_bug.cgi?id=15334 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|ian at airs dot com |ccoutant at google dot com --- Comment #1 from Cary Coutant 2013-04-03 19:01:27 UTC --- I'll work on documentation for this. -- 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 gold/15341] debug_msg.sh make check fails
http://sourceware.org/bugzilla/show_bug.cgi?id=15341 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|ian at airs dot com |ccoutant at google dot com --- Comment #1 from Cary Coutant 2013-04-12 18:42:38 UTC --- What target are you building for? What compiler and version? Can you attach these .o files from gold/testsuite: debug_msg.o odr_violation1.o odr_violation2.o -- 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 gold/15341] debug_msg.sh make check fails
http://sourceware.org/bugzilla/show_bug.cgi?id=15341 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX --- Comment #11 from Cary Coutant 2013-04-15 22:46:59 UTC --- Disassembly from odr_violation1.o: <_ZN10OdrDerivedD0Ev>: ~OdrDerived(): /usr/local/src/xxx-devel/binutils-2.23.2-gold/binutils-build/gold/testsuite/../../../gold/testsuite/odr_header1.h:4 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: 48 83 ec 10 sub$0x10,%rsp 8: 48 89 7d f8 mov%rdi,-0x8(%rbp) c: ba 00 00 00 00 mov$0x0,%edx 11: 48 8b 45 f8 mov-0x8(%rbp),%rax 15: 48 89 10mov%rdx,(%rax) Disassembly from odr_violation2.o: <_ZN10OdrDerivedD0Ev>: ~OdrBase(): /usr/local/src/xxx-devel/binutils-2.23.2-gold/binutils-build/gold/testsuite/../../../gold/testsuite/odr_header2.h:2 0: 48 c7 07 00 00 00 00movq $0x0,(%rdi) Gold is comparing "odr_header1.h:4" and "odr_header2.h:2" and concluding that these are two different functions. We've got a bunch of heuristics to try to cope with inconsistent line number information, but none of them work here. This was built, from what I saw in your config.log with GCC 4.1, so I'm inclined to close this as a compiler problem that has been fixed in more recent versions. It would be nice if we could mark this test as "unsupported" when we're using a compiler that's known not to generate good enough line numbers, but I'm not really sure what kind of check to run. I guess I could just run objdump -dl on these two .o files and scan for expected output before running the test, but there are still a lot of variations that should be accepted. I'm open to suggestions. -- 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 gold/15341] debug_msg.sh make check fails
http://sourceware.org/bugzilla/show_bug.cgi?id=15341 --- Comment #12 from Cary Coutant 2013-04-15 22:48:39 UTC --- (In reply to comment #10) > Did not find expected error in debug_msg.err: >: symbol 'SometimesInlineFunction(int)' defined in multiple places > (possible > ODR violation): This is different. Please open a new bug for it (and attach the same set of .o files). -- 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 gold/15447] dwp crashes with fseek(NULL) when executable without any .dwo files is specified
http://sourceware.org/bugzilla/show_bug.cgi?id=15447 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|ian at airs dot com |ccoutant at google 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 gas/15457] GAS should generate DW_FORM_strp when emitting debug info
http://sourceware.org/bugzilla/show_bug.cgi?id=15457 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at sourceware|ccoutant at google dot com |dot org | -- 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 gold/15478] -no-as-needed required to avoid runtime symbol lookup error
http://sourceware.org/bugzilla/show_bug.cgi?id=15478 --- Comment #1 from Cary Coutant 2013-05-16 23:51:51 UTC --- > situation (see attached tar.bz2 to reproduce): > libmylib.so has unresolved symbols that are found in libmyplugin.so > myapp.c++ calls into libmylib.so > myapp.c++ is being compiled with -lmylib and -lmyplugin > > expected behaviour, and behaviour with gnu ld: > myapp is linked against mylib and myplugin > > observed behaviour: > myapp is only linked against mylib since it does not make direct calls into > myplugin > myapp is not executable (fails with message about myplugin symbols not being > resolved in mylib) > > workaround: > link with -no-as-needed > > Can you comment on this observed behaviour? thanks I think this is intended behavior for gold. It's expected that each library will have its own dependencies recorded so that we only record direct dependencies in the dynamic table. In your case, since libmylib.so has references to libmyplugin.so, there should be a DT_NEEDED entry in libmylib.so for libmyplugin.so. If you link libmylib.so with -L. -lmyplugin, it should work. -cary -- 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 gold/15478] -no-as-needed required to avoid runtime symbol lookup error
http://sourceware.org/bugzilla/show_bug.cgi?id=15478 --- Comment #3 from Cary Coutant 2013-05-17 04:50:56 UTC --- > Yes that mode of operation does work but is unfortunately not an option for us > as we would like to combine libmylib.so with a different API-compatible > libmyplugin.so in each of a whole range of myapp executables. To resolve the > symbol in the libmylib.so build would mean building a number of libmylib.so > (one for each libmyplugin.so) and this would make our build take much more > time, as well as inflating the size of our releases. > > It seems that it should be fairly easy for gold to broaden its 'as-needed' > criteria by scanning for unresolved symbols in the .so files (as well as in > the > .o files) being linked. That would seem to make the behaviour compatible with > the old behaviour of the old linker. I think this is a behavior of the Gnu linker that gold is better off not copying. The linker ends up having to replicate the path searching done at runtime by the dynamic loader, and that works only when the libraries are in their installed locations. Making that work at development time leads to all kinds of unexpected behavior. > If that's not possible then -no-as-needed should be the default I think. It is the default in gold, but GCC recently started passing --as-needed to the linker by default. -cary -- 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 gold/15478] -no-as-needed required to avoid runtime symbol lookup error
http://sourceware.org/bugzilla/show_bug.cgi?id=15478 --- Comment #5 from Cary Coutant 2013-05-17 18:48:34 UTC --- >> I think this is a behavior of the Gnu linker that gold is better off >> not copying. The linker ends up having to replicate the path searching >> done at runtime by the dynamic loader, and that works only when the >> libraries are in their installed locations. Making that work at >> development time leads to all kinds of unexpected behavior. > > I don't see any need for additional searching. The linker already has to > search for the library through the paths specified by -L, and it needs to read > the library to ensure that unresolved symbols in the .o files can be bound in > the libraries. So all the information is already available. In this specific case, yes, no searching is necessary, but in the general case, if we're going to try to resolve undefined symbols in shared libraries, we need to process the dependencies of those shared libraries, which means trying to find them via the embedded rpaths in those libraries. -cary -- 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 gold/15478] -no-as-needed required to avoid runtime symbol lookup error
http://sourceware.org/bugzilla/show_bug.cgi?id=15478 --- Comment #9 from Cary Coutant 2013-05-20 16:46:00 UTC --- > Here is the documentation from older binutils which talks about --as-needed > interpreting undefined symbols both .o and .so files: > >--as-needed >--no-as-needed >This option affects ELF DT_NEEDED tags for >dynamic libraries mentioned on the command line >after the --as-needed option. Normally the >linker will add a DT_NEEDED tag for each dynamic >library mentioned on the command line, >regardless of whether the library is actually >needed or not. --as-needed causes a DT_NEEDED >tag to only be emitted for a library that >satisfies an undefined symbol reference from a >regular object file or, if the library is not >found in the DT_NEEDED lists of other libraries >linked up to that point, an undefined symbol >reference from another dynamic library. >--no-as-needed restores the default behaviour. That is rather explicit, isn't it? For gold to match this behavior, I think all we need to do is remove the test for sym->in_reg() in the following code in Symbol_table::set_dynsym_indexes: // If the symbol is defined in a dynamic object and is // referenced strongly in a regular object, then mark the // dynamic object as needed. This is used to implement // --as-needed. if (sym->is_from_dynobj() && sym->in_reg() && !sym->is_undef_binding_weak()) sym->object()->set_is_needed(); Ian, what do you think? -cary -- 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 gold/15478] -no-as-needed required to avoid runtime symbol lookup error
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #10 from Cary Coutant 2013-05-20
17:41:58 UTC ---
> That is rather explicit, isn't it? For gold to match this behavior, I
> think all we need to do is remove the test for sym->in_reg() in the
> following code in Symbol_table::set_dynsym_indexes:
>
> // If the symbol is defined in a dynamic object and is
> // referenced strongly in a regular object, then mark the
> // dynamic object as needed. This is used to implement
> // --as-needed.
> if (sym->is_from_dynobj()
> && sym->in_reg()
> && !sym->is_undef_binding_weak())
>sym->object()->set_is_needed();
Close, but not quite. If the symbol isn't referenced from the main
program, we won't be adding a dynsym entry for it, so the test for
as-needed needs to be copied to the if clause just above:
diff --git a/gold/symtab.cc b/gold/symtab.cc
index 2e17529..595df56 100644
--- a/gold/symtab.cc
+++ b/gold/symtab.cc
@@ -2381,7 +2381,17 @@ Symbol_table::set_dynsym_indexes(unsigned int index,
// and without a version.
if (!sym->should_add_dynsym_entry(this))
- sym->set_dynsym_index(-1U);
+ {
+ sym->set_dynsym_index(-1U);
+ // If the symbol is defined in a dynamic object and is
+ // referenced strongly in a dynamic object, then mark the
+ // dynamic object as needed. This is used to implement
+ // --as-needed. This is for compatibility with the GNU
+ // linker.
+ if (sym->is_from_dynobj()
+ && !sym->is_undef_binding_weak())
+ sym->object()->set_is_needed();
+ }
else if (!sym->has_dynsym_index())
{
sym->set_dynsym_index(index);
I've added a test case for this, too. Ian, if you think this is
reasonable, I'll go ahead and commit it.
-cary
--
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 gold/15478] -no-as-needed required to avoid runtime symbol lookup error
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #11 from Cary Coutant 2013-05-20
21:43:58 UTC ---
> diff --git a/gold/symtab.cc b/gold/symtab.cc
> index 2e17529..595df56 100644
> --- a/gold/symtab.cc
> +++ b/gold/symtab.cc
> @@ -2381,7 +2381,17 @@ Symbol_table::set_dynsym_indexes(unsigned int index,
>// and without a version.
>
>if (!sym->should_add_dynsym_entry(this))
> - sym->set_dynsym_index(-1U);
> + {
> + sym->set_dynsym_index(-1U);
> + // If the symbol is defined in a dynamic object and is
> + // referenced strongly in a dynamic object, then mark the
> + // dynamic object as needed. This is used to implement
> + // --as-needed. This is for compatibility with the GNU
> + // linker.
> + if (sym->is_from_dynobj()
> + && !sym->is_undef_binding_weak())
> + sym->object()->set_is_needed();
> + }
>else if (!sym->has_dynsym_index())
> {
> sym->set_dynsym_index(index);
>
> I've added a test case for this, too. Ian, if you think this is
> reasonable, I'll go ahead and commit it.
Still not quite there. This patch breaks --as-needed completely,
always marking every shared library as needed.
The more I try to make this work and think about the complications,
the more I think gold is already doing it right. Gold doesn't
currently track whether a symbol defined in a shared object is
referenced by a different shared object. Even if it did, we'd have to
keep track of all such references and do a transitive closure on each
reference to make sure that the reference comes from a "needed"
library before marking the new library as "needed". I'm now retreating
to my earlier position that this is not something we want gold to
support. We should be encouraging proper program structure where each
load module declares its direct dependencies, and only its direct
dependencies.
I guess that means we should document somewhere what the difference is
between Gnu ld and gold. I don't think changing the name of the option
is right, because it's a subtle difference that arguably affects only
programs whose dependencies are already improperly recorded. But since
Gnu ld does explicitly cover this particular case, we should probably
say something. We don't have a gold manual, nor do we have a document
that lists the differences between Gnu ld and gold -- we should have
at least one of those, but until we do, should we just edit the help
text? I'm not sure how to describe this difference in an economical
way that will fit in the help text.
-cary
--
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 gold/15574] Gold is overly pedantic for dynamic references to symbols with hidden visibility
http://sourceware.org/bugzilla/show_bug.cgi?id=15574 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|ccoutant at google 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/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #2 from Cary Coutant --- Is there any way that you can shrink the extent of the --start-group/--end-group options? My first guess is that it's related to having all those files inside the library group. In particular, .o files do not need to be inside the group. It might be better to build a thin archive from all those .a files, then just link against the thin archive (the linker will treat all the nested member libraries as one giant archive library). -- 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/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #4 from Cary Coutant --- > Next step was to create one large archive, so: > > ar r [list of all *.a] /tmp/lib.a > > g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L. -flto=9 > -fno-fat-lto-objects -O2 --param lto-partitions=64 -o chrome > obj/chrome/app/chrome.chrome_exe_main_gtk.o > obj/chrome/app/chrome.chrome_main.o > obj/chrome/app/chrome.chrome_main_delegate.o /tmp/lib.a -lX11 -lXcursor > -lXrandr -lXrender -lXss -lXext -lrt -ldl -lgmodule-2.0 -lgobject-2.0 > -lgthread-2.0 -lglib-2.0 -lXtst -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 > -lgio-2.0 > -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 > -lfreetype > -lfontconfig -lXi -lsmime3 -lnssutil3 -lnss3 -lplds4 -lplc4 -lnspr4 -lgconf-2 > -lresolv -lXcomposite -lasound -lXdamage -lXfixes -lcups -lgnutls -lgcrypt > -lgpg-error -lz -lpthread -lcrypt -lm -L/usr/lib64 -lexpat -ldbus-1 -ludev > > I was shown big amount of undefined symbols, did I use the correct way how to > create the archive? You need the 'T' option to make a thin archive. Otherwise an archive of other archives makes a plain non-library archive file. -cary -- 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/15660] out of file descriptors and couldn't close any
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #6 from Cary Coutant --- Does the problem only happen with -flto? I wonder if the plugin is keeping files open. Can you tar up the build directory so I can try to repro the problem? -cary On Thu, Jun 20, 2013 at 1:43 PM, marxin.liska at gmail dot com wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=15660 > > Bug ID: 15660 >Summary: out of file descriptors and couldn't close any >Product: binutils >Version: 2.23 > Status: NEW > Severity: normal > Priority: P2 > Component: gold > Assignee: ian at airs dot com > Reporter: marxin.liska at gmail dot com > CC: ccoutant at google dot com > > I've encountered similar bug to: > http://sourceware.org/bugzilla/show_bug.cgi?id=10708 during linking of > chromium > binary. > > ld --version > GNU gold (GNU Binutils 2.23.52.20130526) 1.11 > > Command line: > FAILED: flock linker.lock g++ -Wl,-z,now -Wl,-z,relro -pthread > -Wl,-z,noexecstack -fPIC -pie -L. -flto=9 -fno-fat-lto-objects -O2 --param > lto-partitions=64 -o chrome -Wl,--start-group > obj/chrome/app/chrome.chrome_exe_main_gtk.o > obj/chrome/app/chrome.chrome_main.o > obj/chrome/app/chrome.chrome_main_delegate.o obj/chrome/libinstaller_util.a > obj/media/libmedia_sse.a obj/third_party/icu/libicuuc.a > obj/third_party/libjingle/libjingle.a obj/skia/libskia_opts.a > obj/third_party/icu/libicudata.a > obj/device/libdevice_media_transfer_protocol.a > obj/native_client/src/trusted/service_runtime/arch/x86/libservice_runtime_x86_common.a > obj/chrome/libservice.a obj/chrome/librenderer.a obj/webkit/support/libglue.a > obj/content/libcontent_worker.a obj/third_party/libwebp/libwebp_utils.a > obj/third_party/zlib/libminizip.a > obj/chrome/browser/performance_monitor/libperformance_monitor.a > obj/third_party/leveldatabase/libleveldatabase.a > obj/native_client/src/trusted/service_runtime/libenv_cleanser.a > obj/sandbox/libc_urandom_override.a obj/chrome/libbrowser.a > obj/ppapi/libppapi_host.a obj/sync/libsync_core.a > obj/gpu/libgles2_cmd_helper.a > obj/third_party/smhasher/libcityhash.a > obj/third_party/libphonenumber/libphonenumber.a > obj/chrome/app/policy/libpolicy.a obj/webkit/support/libplugins_common.a > obj/native_client/src/trusted/validator_x86/libnccopy_x86_64.a > obj/webkit/support/libglue_common.a > obj/webkit/renderer/compositor_bindings/libwebkit_compositor_support.a > obj/third_party/smhasher/libmurmurhash3.a obj/content/libcontent_gpu.a > obj/native_client/src/trusted/threading/libthread_interface.a > obj/media/libmedia_mmx.a obj/ipc/libipc.a obj/third_party/libxslt/libxslt.a > obj/remoting/libremoting_client.a obj/third_party/ots/libots.a > obj/base/libsymbolize.a > obj/native_client/src/trusted/validator/libvalidators.a > obj/chrome/libbrowser_extensions.a obj/skia/libskia_opts_ssse3.a > obj/third_party/protobuf/libprotobuf_lite.a > obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform.a > obj/ui/surface/libsurface.a > obj/third_party/WebKit/Source/WebKit/chromium/libwebkit.a > obj/native_client/src/trusted/validator/x86/64/libncvalidate_x86_64.a > obj/third_party/jsoncpp/libjsoncpp.a obj/google_apis/libgoogle_apis.a > obj/chrome/libnacl.a > obj/third_party/libphonenumber/libphonenumber_without_metadata.a > obj/chrome/libdebugger.a obj/v8/tools/gyp/libv8_snapshot.a > obj/ui/native_theme/libnative_theme.a obj/third_party/libusb/libusb.a > obj/content/libcontent_common_child.a > obj/native_client/src/trusted/nacl_base/libnacl_base.a > obj/base/libbase_static.a obj/native_client/src/shared/imc/libimc.a > obj/chrome/libfeedback_proto.a > obj/components/libbrowser_context_keyed_service.a > obj/components/libweb_modal.a > obj/chrome/libapps.a > obj/third_party/WebKit/Source/core/core.gyp/libwebcore_platform_geometry.a > obj/components/libuser_prefs.a obj/content/libcontent_utility.a > obj/third_party/libevent/libevent.a obj/sandbox/libseccomp_bpf.a > obj/build/linux/libpci.a obj/ui/gl/libgl_wrapper.a > obj/third_party/mt19937ar/libmt19937ar.a > obj/third_party/angle/src/libtranslator_common.a > obj/ui/message_center/libmessage_center.a obj/third_party/libpng/libpng.a > obj/components/libwebdata_common.a obj/third_party/opus/libopus.a > obj/sync/libsync_notifier.a obj/ui/snapshot/libsnapshot.a > obj/native_client/src/trusted/validator/x86/libncval_base_x86_64.a > obj/webkit/support/libwebkit_media.a obj/third_party/libwebp/libwebp_dsp.a > obj/third_party/harfbuzz-ng/libharfbuzz-ng.a > obj/chrome/app/policy/libcloud_policy_proto_generated_compile.a > obj/base/allocator/liballocator_extension_thunks.a > obj/remoting/lib
[Bug gold/15662] gold (powerpc) internal error in do_relax() at gold/output.h:436
http://sourceware.org/bugzilla/show_bug.cgi?id=15662
--- Comment #1 from Cary Coutant ---
> Index: powerpc.cc
> ===
> RCS file: /cvs/src/src/gold/powerpc.cc,v
> retrieving revision 1.91
> diff -r1.91 powerpc.cc
> 2631a2632
>> this->brlt_section_->reset_rel_data_size();
> 2638a2640
>> this->brlt_section_->finalize_rel_data_size();
This looks right to me, but Alan should confirm.
I'd suggest, instead of adding a second call at each point, replacing
the call to reset_data_size and finalize_data_size with calls to
reset_brlt_sizes and finalize_brlt_sizes, and have those functions
make both calls that are needed.
> 3015a3018,3029
>> void
>> reset_rel_data_size()
>> {
>> this->rel_->reset_data_size();
>> }
>>
>> void
>> finalize_rel_data_size()
>> {
>> this->rel_->finalize_data_size();
>> }
These member functions would then become:
void
reset_brlt_sizes()
{
this->reset_data_size();
this->rel_->reset_data_size();
}
void
finalize_brlt_sizes()
{
this->finalize_data_size();
this->rel_->finalize_data_size();
}
(By the way, in the future, please use 'diff -up' to generate your
patches -- it makes them much easier to read.)
-cary
--
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/15662] gold (powerpc) internal error in do_relax() at gold/output.h:436
http://sourceware.org/bugzilla/show_bug.cgi?id=15662 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|ian at airs dot com|ccoutant at google dot com --- Comment #3 from Cary Coutant --- Fixed on trunk. -- 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/15070] gold crashes on ARMv5 due to unaligned memory access
http://sourceware.org/bugzilla/show_bug.cgi?id=15070 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Cary Coutant --- I've applied Shawn's patch and updated the comment in fileread.h. -cary -- 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/15758] Gold segfault when using -q option
http://sourceware.org/bugzilla/show_bug.cgi?id=15758 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google dot com --- Comment #1 from Cary Coutant --- I'll take a look. -- 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/15769] Internal error in emit_relocs_scan
http://sourceware.org/bugzilla/show_bug.cgi?id=15769 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Cary Coutant --- Duplicate of PR gold/15758. *** This bug has been marked as a duplicate of bug 15758 *** -- 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/15758] Gold segfault when using -q option
http://sourceware.org/bugzilla/show_bug.cgi?id=15758 Cary Coutant changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Cary Coutant --- *** Bug 15769 has been marked as a duplicate of this bug. *** -- 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/14342] [gold] symbol 'std::__once_callable' used as both __thread and non-__thread
http://sourceware.org/bugzilla/show_bug.cgi?id=14342 --- Comment #2 from Cary Coutant --- > This problem now reprduce with mainline GCC indirect call profiling test > gcc.dg/tree-prof/crossmodule-indircall-1.c: > > evans:/abuild/jh/trunk-3/build-inst11-check/gcc/:[2]# ./xgcc -B ./ -O3 -flto > -fprofile-generate > ../../gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1*.c --save-temps > /abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld: > crossmodule-indircall-1.o: previous definition here > /abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld: error: > ./libgcov.a(_gcov_indirect_call_profiler.o): symbol > '__gcov_indirect_call_callee' used as both __thread and non-__thread > /abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld: > crossmodule-indircall-1.o: previous definition here I get: .../gold/ld-new: error: crossmodule-indircall-1.o: multiple definition of 'main' .../gold/ld-new: crossmodule-indircall-1a.o: previous definition here If I add -DDOJOB=1 to the command line, though, it works for me. Are you using a recent version of gold? I think the TLS problem should have been fixed with this patch: http://sourceware.org/ml/binutils/2013-06/msg00139.html -cary -- 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/14342] [gold] symbol 'std::__once_callable' used as both __thread and non-__thread
http://sourceware.org/bugzilla/show_bug.cgi?id=14342 --- Comment #4 from Cary Coutant --- >> Are you using a recent version of gold? I think the TLS problem should >> have been fixed with this patch: >> >> http://sourceware.org/ml/binutils/2013-06/msg00139.html > > This indeed looks like exactly the problem I hit. I checked only the > release versions of gold, not trunk, so guess it is fixed now. > > Was the same problem fixed on GNU ld side, too? I thought GNU ld didn't have this bug, but I'll check. -cary -- 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/15984] Segfault when using static __thread function variables with intel compiler
http://sourceware.org/bugzilla/show_bug.cgi?id=15984 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|ccoutant at google dot com --- Comment #1 from Cary Coutant --- Can you attach a .o file, please? -- 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/16010] Incorrect dependency in gold/testsuite
https://sourceware.org/bugzilla/show_bug.cgi?id=16010 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|ian at airs dot com|ccoutant at google dot com --- Comment #2 from Cary Coutant --- Patch committed: https://sourceware.org/ml/binutils-cvs/2013-10/msg00022.html -- 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/16085] gold assumes STT_NOTYPE symbols are not thumb
https://sourceware.org/bugzilla/show_bug.cgi?id=16085 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|dougkwan at google 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/16094] ld searches LIBRARY_PATH and LD_LIBRARY_PATH but gold only searches LIBRARY_PATH
https://sourceware.org/bugzilla/show_bug.cgi?id=16094 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Cary Coutant --- Yes, it's intentional. LD_LIBRARY_PATH is the run-time search path for dynamic libraries, while LIBRARY_PATH is the link-time search path for libraries. The Gnu linker searches for dynamic libraries with LD_LIBRARY_PATH while resolving symbolic references across shared libraries, and attempts to reproduce the dynamic linker's searching behavior. Gold, by design, does not do this. -- 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/14860] gold_assert(oview_size == 8) fails in Eh_frame_hdr::do_sized_write()
https://sourceware.org/bugzilla/show_bug.cgi?id=14860 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|ccoutant at google 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/16108] gold .gdb_index version 7 support is missing
https://sourceware.org/bugzilla/show_bug.cgi?id=16108 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|ccoutant at google 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/15758] Gold segfault when using -q option
https://sourceware.org/bugzilla/show_bug.cgi?id=15758 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Cary Coutant --- Fixed on trunk. -- 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/16203] gold -ldl link fails on Gentoo/FreeBSD
https://sourceware.org/bugzilla/show_bug.cgi?id=16203 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|ian at airs dot com|ccoutant at google dot com --- Comment #3 from Cary Coutant --- I applied a variant of the proposed patch. Fixed on binutils trunk. -- 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/13577] Gold linker does not respect --dynamic-list option
https://sourceware.org/bugzilla/show_bug.cgi?id=13577 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|ccoutant at google dot com --- Comment #3 from Cary Coutant --- > Bump. Anyone working on that? Sorry, no one that I know of. Gold's implementation of --dynamic-list seems to do nothing more than force the linker to create a dynamic symbol table entry for it -- it does not undo the effect of -Bsymbolic or protected visibility. My interpretation of the Gnu ld manual is that gold is in fact wrong here. The fix should be a simple patch to Symbol::is_preemptible() in symtab.h. I'll try to get a patch in soon. -cary -- 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/16341] relative paths in ld.script break gold linker
https://sourceware.org/bugzilla/show_bug.cgi?id=16341 --- Comment #1 from Cary Coutant --- Relative paths in the script file are interpreted relative to the directory where the script file lives. Failing that, the normal library search path is used. The first part makes sense to me, and it seems that Gnu ld ought to at least do that. Using the library search path for a regular file name (i.e., not a -l option) seems strange, but that's copied from Gnu ld. Looking for files relative to the current directory doesn't seem like the right thing to do, but I suppose it's a reasonable last choice. Experimenting with Gnu ld... I created a subdir/ld.script that contains "INPUT(sub1.o)", and linking with gcc -Wl,-t -L lib main.o -t subdir/ld.script (a) With ./sub1.o, lib/sub1.o, and subdir/sub1.o, Gnu ld chooses ./sub1.o. (b) With just lib/sub1.o and subdir/sub1.o, Gnu ld chooses lib/sub1.o. (c) With just subdir/sub1.o, Gnu ld can't find sub1.o. So the one place that makes the most sense to me is the one place that Gnu ld doesn't look for the file! If you add "-L ." to the link command, gold should find the file relative to the current directory, and it will if the filename is just a path (with no slashes). If the filename in the script is a relative path (e.g., "lib/sub1.o"), gold doesn't find it relative to the current directory. I think that's a bug -- according the the --debug=files output, it tries "./lib/sub1.o", but gold's directory search only works for bare filenames. -- 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/16444] readelf should print contents of NT_GNU_GOLD_VERSION note
https://sourceware.org/bugzilla/show_bug.cgi?id=16444 Cary Coutant changed: What|Removed |Added CC||ccoutant at google dot com Assignee|unassigned at sourceware dot org |ccoutant at google 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/16417] executable linked with gold segfaults before main
https://sourceware.org/bugzilla/show_bug.cgi?id=16417 --- Comment #1 from Cary Coutant --- I tried compiling with a 4.9.0 compiler, but my copy doesn't have the -floop-* options implemented. Compiling without those options does not reproduce the problem. Can you attach your .o 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
[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 #5 from Cary Coutant --- Sorry, I had this on my list, but it dropped down to the bottom. I'll take a look at it this week. It's always good to ping! -- 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/16446] internal error in find_runnable_or_wait, at workqueue.cc:263
https://sourceware.org/bugzilla/show_bug.cgi?id=16446 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google 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/16417] executable linked with gold segfaults before main
https://sourceware.org/bugzilla/show_bug.cgi?id=16417 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google 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/16389] gold throws "internal error in segment_precedes" when building VirtualBox
https://sourceware.org/bugzilla/show_bug.cgi?id=16389 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google dot com --- Comment #2 from Cary Coutant --- Please attach the linker script and the .o files. -- 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 Cary Coutant changed: What|Removed |Added Status|REOPENED|ASSIGNED --- Comment #6 from Cary Coutant --- For the repro in commend #1, you need to move the .bss section out of the DISCARD clause. When you compile with LTO, the compiler adds a COMMON symbol, __gnu_lto_v1, to the symbol table, which the linker tries to allocate in .bss. Without that section declared in the script, gold hits an internal error. The original problem report is probably the same issue. Of course, this shouldn't be an internal error -- we should provide a reasonable diagnostic for this case. I'll work on that. -- 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/16530] --dynamic-list does not protect symbols from being garbage collected
https://sourceware.org/bugzilla/show_bug.cgi?id=16530 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google 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/16446] internal error in find_runnable_or_wait, at workqueue.cc:263
http://sourceware.org/bugzilla/show_bug.cgi?id=16446 --- Comment #1 from Cary Coutant --- Can you run it again with --debug=task and attach the output, please? -cary On Mon, Jan 13, 2014 at 11:08 PM, thestig at google dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=16446 > > Bug ID: 16446 >Summary: internal error in find_runnable_or_wait, at > workqueue.cc:263 >Product: binutils >Version: 2.23 > Status: NEW > Severity: normal > Priority: P2 > Component: gold > Assignee: ian at airs dot com > Reporter: thestig at google dot com > CC: ccoutant at google dot com > > Build Chromium r244583 on 64-bit Linux with > GYP_DEFINES="component=shared_library". When linking the chrome binary, > instead > of just passing flags like --threads --thread-count=4 to gold, also pass in > --preread-archive-symbols. > > The gold binary used is a pre-built copy checked into Chromium's > third_party/gold. > > Expected: build completes successfully > Actually: gold fails with "internal error in find_runnable_or_wait, at > workqueue.cc:263" > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- 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/16108] gold .gdb_index version 7 support is missing
https://sourceware.org/bugzilla/show_bug.cgi?id=16108 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Cary Coutant --- This was fixed with this commit: https://sourceware.org/ml/binutils-cvs/2014-01/msg00156.html -- 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/13577] Gold linker does not respect --dynamic-list option
https://sourceware.org/bugzilla/show_bug.cgi?id=13577 --- Comment #4 from Cary Coutant --- It was a bit more complicated. The --dynamic-list option is actually mutually exclusive with -Bsymbolic and -Bsymbolic-functions. If a dynamic list is given, the Gnu linker makes only those symbols preemptible, and binds the remaining symbols within the library. I've changed gold to do the same thing. -- 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/13577] Gold linker does not respect --dynamic-list option
https://sourceware.org/bugzilla/show_bug.cgi?id=13577 Cary Coutant changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Cary Coutant --- Fixed on trunk. -- 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/16530] --dynamic-list does not protect symbols from being garbage collected
https://sourceware.org/bugzilla/show_bug.cgi?id=16530 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Cary Coutant --- Fixed on trunk. -- 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/15435] Gold rejects undefined weak hidden symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=15435 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Cary Coutant --- Fixed on trunk. -- 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/16533] Gold does not set HASENTRY attribute on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=16533 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|dougkwan at google 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 binutils/16444] readelf should print contents of NT_GNU_GOLD_VERSION note
https://sourceware.org/bugzilla/show_bug.cgi?id=16444 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Cary Coutant --- Fixed on trunk. -- 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/16544] Gold crashes with plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=16544 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ian at airs dot com|ccoutant at google dot com --- Comment #2 from Cary Coutant --- The problem is that gold hasn't yet seen any real (i.e., non-plugin) .o files to establish what the target architecture is. Before plugins, this really was a "can't happen" path; hence the internal error. It shouldn't be diagnosed as an internal error in this case, but we really need to see a real .o before anything else. Normally, the compiler passes in various startup files. There's no simple way of relaxing this requirement, short of changing the plugin API to allow the plugin to specify the target architecture if necessary. I can fix it to print a real diagnostic, but I don't plan to support the case where all input files are claimed by the plugin. -- 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/15660] out of file descriptors and couldn't close any
https://sourceware.org/bugzilla/show_bug.cgi?id=15660 Cary Coutant changed: What|Removed |Added Status|NEW |WAITING Assignee|ian at airs dot com|ccoutant at google dot com --- Comment #10 from Cary Coutant --- Waiting for a tarball for repro. -- 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/16650] PREVAILING_DEF / PREVAILING_DEF_IRONLY_EXP mix-up
https://sourceware.org/bugzilla/show_bug.cgi?id=16650 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google 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/16691] Unexpected UNDEFs in resolution files
https://sourceware.org/bugzilla/show_bug.cgi?id=16691 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google 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/16693] "exclude-libs" drops symbols that are exported through "dynamic-list" or "export-dynamic-symbol"
https://sourceware.org/bugzilla/show_bug.cgi?id=16693 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google 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/16693] "exclude-libs" drops symbols that are exported through "dynamic-list" or "export-dynamic-symbol"
https://sourceware.org/bugzilla/show_bug.cgi?id=16693 --- Comment #8 from Cary Coutant --- > Test modified to --version-script and --exclude-libs=ALL > > With --exclude-libs=ALL function dynamic_list_exported_from_static_lib() is > not > exported. If you're using a version script, you shouldn't need --exclude-libs at all. -cary -- 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/16693] "exclude-libs" drops symbols that are exported through "dynamic-list" or "export-dynamic-symbol"
https://sourceware.org/bugzilla/show_bug.cgi?id=16693 --- Comment #9 from Cary Coutant --- > --dynamic-list isn't used to control which symbols are exported or > not. From ld manual: > > '--dynamic-list=DYNAMIC-LIST-FILE' > Specify the name of a dynamic list file to the linker. This is > typically used when creating shared libraries to specify a list of > global symbols whose references shouldn't be bound to the > definition within the shared library, or creating dynamically > linked executables to specify a list of symbols which should be > added to the symbol table in the executable. This option is only > meaningful on ELF platforms which support shared libraries. True, but a necessary side effect of not binding a symbol within the library is exporting it via the dynamic symbol table. This option is commonly used to ensure specific symbols are exported (it's basically -Bsymbolic with a list of exceptions), but it doesn't *remove* any of the locally-bound symbols from the dynamic symbol table. The --exclude-libs option does that for symbols defined in the named libraries, but also prevents symbols in the dynamic list from being added. That, I think, is a bug. A version script ought to also work (and is probably more appropriate for Viatcheslav's application), but I still think --dynamic-list ought to export a symbol even if it comes from an excluded library. --exclude-libs lib,lib,... Specifies a list of archive libraries from which symbols should not be automatically exported. The library names may be delimited by commas or colons. Specifying --exclude-libs ALL excludes symbols in all archive libraries from automatic export. Note that it says *automatic* export. To me that implies that symbols explicitly exported should still be exported. -cary -- 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/16693] "exclude-libs" drops symbols that are exported through "dynamic-list" or "export-dynamic-symbol"
https://sourceware.org/bugzilla/show_bug.cgi?id=16693 --- Comment #11 from Cary Coutant --- > IMHO, --version-script option needs better doc. I could never guess from > current "--version-script" description in man (which has just "Read version > script"), that it can manage any shared library exports. See https://sourceware.org/binutils/docs-2.24/ld/VERSION.html#VERSION -cary -- 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/16693] "exclude-libs" drops symbols that are exported through "dynamic-list" or "export-dynamic-symbol"
https://sourceware.org/bugzilla/show_bug.cgi?id=16693 --- Comment #13 from Cary Coutant --- > When building shared library, --dynamic-list doesn't change the > dynamic symbol table, i.e., > > ld -shared --dynamic-list ... > > and > > ld -shared ... > > generate the same dynamic symbol table. From this point of view, > > ld -shared --exclude-libs=ALL --dynamic-list ... > > and > > ld -shared --exclude-libs=ALL ... > > generate the same dynamic symbol table isn't a bug. OK. Version scripts are a much better way to control what goes into the dynamic symbol table, so I don't think there's any value in changing the behavior the way I was suggesting. -cary -- 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/16728] gold fails to hide hidden tls symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=16728 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google 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/16389] gold throws "internal error in segment_precedes" when building VirtualBox 4.3.6
https://sourceware.org/bugzilla/show_bug.cgi?id=16389 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Cary Coutant --- This is probably a duplicate of PR 15355, which has been fixed in binutils-2.24. If this is still a problem, please reopen with object files for repro. *** This bug has been marked as a duplicate of bug 15355 *** -- 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/15355] ppc64 linker script failure
https://sourceware.org/bugzilla/show_bug.cgi?id=15355 Cary Coutant changed: What|Removed |Added CC||alex_y_xu at yahoo dot ca --- Comment #5 from Cary Coutant --- *** Bug 16389 has been marked as a duplicate of this bug. *** -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #9 from Cary Coutant --- > > Yes, in gold, the fill value is always 4 bytes in length. There's a FIXME in > > the code to support arbitrary lengths, but that seems unlikely to be the > > problem here. > > Fixing it for one and two bytes would be trivial :) How does GNU ld determine the size? In gold, we treat the fill value as an arbitrary expression, so by the time we get the actual value to use, we have no idea how large the given value was. If it's based on the size of the constant given (e.g., 0x9090 is two bytes and 0x9090 is four bytes), it's not trivial. If it's simply based on the magnitude (e.g., 0x9090 and 0x9090 are both two bytes), then yes, it probably is trivial -- but then how would you express a fill pattern like 0x9090 where you really want 00 00 90 90 00 00 90 90 ...? -- 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #6 from Cary Coutant --- (In reply to Andy Lutomirski from comment #4) > It looks like gold has a different interpretation of what ":text = 0x9090" > means than the bfd linker. Can you try changing that to ":text = > 0x90909090" in arch/x86/kernel/vmlinux.lds.S? > > This is definitely a gold bug, or at least a difference between gold and > bfd, but I doubt it's causing your problem, since using :text = 0x9090 > on bfd still produces a working kernel for me. > > That being said, I just generated a working kernel with GNU gold (version > 2.23.2) 1.11. Can you post a kernel image or a config or something? Yes, in gold, the fill value is always 4 bytes in length. There's a FIXME in the code to support arbitrary lengths, but that seems unlikely to be the problem 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/16788] Gold produces unbootable Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=16788 --- Comment #8 from Cary Coutant --- > -8100021e: 48 c7 c7 10 e7 75 81mov > $0x8175e710,%rdi > +8100021e: 48 c7 c7 c8 cf 78 81mov > $0x8178cfc8,%rdi > -810002cc: 48 c7 c7 3a e6 75 81mov > $0x8175e63a,%rdi > +810002cc: 48 c7 c7 6c e6 75 81mov > $0x8175e66c,%rdi Differences like these could be the problem, but it's more likely that these just reflect slight differences in layout between the two linkers (the operand addresses are in .rodata). I'm not sure why gold is bumping the text segment up to offset 0x2 in the file, though; it may have something to do with the way we handle ALIGN in the script. Theoretically, the virtual addresses are the same in both files, so the results should be equivalent, but it's possible that the kernel really depends on it starting at 0x1000. -cary -- 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/16417] executable linked with gold segfaults before main
https://sourceware.org/bugzilla/show_bug.cgi?id=16417 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Cary Coutant --- The ld documentation says: --as-needed --no-as-needed This option affects ELF DT_NEEDED tags for dynamic libraries mentioned on the command line after the --as-needed option. Normally the linker will add a DT_NEEDED tag for each dynamic library mentioned on the command line, regardless of whether the library is actually needed or not. --as-needed causes a DT_NEEDED tag to only be emitted for a library that at that point in the link satisfies a non-weak undefined symbol reference from a regular object file or, if the library is not found in the DT_NEEDED lists of other libraries, a non-weak undefined symbol reference from another dynamic library. Object files or libraries appearing on the command line after the library in question do not affect whether the library is seen as needed. This is similar to the rules for extraction of object files from archives. --no-as-needed restores the default behaviour. Note where it says *non-weak*. It seems to me that gold is doing the right thing here and BFD ld is not. -- 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/16804] gold rejects kernel linker script
https://sourceware.org/bugzilla/show_bug.cgi?id=16804
Cary Coutant changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
Assignee|ian at airs dot com|ccoutant at google dot
com
--- Comment #1 from Cary Coutant ---
You need a semicolon after the fill constant:
.text : { *(.text*) } :text =0x90909090;
/DISCARD/ : {
Otherwise, gold attempts to parse the fill spec as an expression: "0x90909090 /
DISCARD ...".
--
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/16804] gold rejects kernel linker script
https://sourceware.org/bugzilla/show_bug.cgi?id=16804 Cary Coutant changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Cary Coutant --- (In reply to Markus Trippelsdorf from comment #2) > Are you sure? > > % ld -T vdso.lds > ld: error: vdso.lds:3:41: syntax error, unexpected ';' > ld: fatal error: unable to parse script file vdso.lds Sorry, my mistake. It needs a comma, not a semicolon. -- 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/16804] gold rejects kernel linker script
https://sourceware.org/bugzilla/show_bug.cgi?id=16804 --- Comment #6 from Cary Coutant --- > This is probably a separate issue, but adding the comma causes: > > ld.gold: internal error in segment_precedes, at layout.cc:3037 Yes, that was PR 15355. It's fixed in binutils-2.24. It was probably caused by having two segments in the PHDRS clause with the same type and flags -- what I've seen before is two PT_NULL segments for vvar_sect and hpet_sect: vvar_sect PT_NULL FLAGS(4); /* PF_R */ hpet_sect PT_NULL FLAGS(4); /* PF_R */ Ideally, instead of using PT_NULL for these segments, you could allocate two new GNU-specific segment types. I think that would have benefits elsewhere, where you can look for these segments by type instead of having to infer which segment is which. -cary -- 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/16804] gold rejects kernel linker script
https://sourceware.org/bugzilla/show_bug.cgi?id=16804
--- Comment #8 from Cary Coutant ---
> Huh? I agree that your suggestion appears to work, but isn't gold supposed to
> speak linker script language as spoken by GNU ld?
We try to get as close as possible, but the two linkers are enough
different that we can't do bug-for-bug compatibility.
> The de facto reference
> (https://sourceware.org/binutils/docs/ld/Output-Section-Description.html#Output-Section-Description)
> says:
>
> section [address] [(type)] :
>[AT(lma)]
>[ALIGN(section_align) | ALIGN_WITH_INPUT]
>[SUBALIGN(subsection_align)]
>[constraint]
>{
> output-section-command
> output-section-command
> ...
>} [>region] [AT>lma_region] [:phdr :phdr ...] [=fillexp]
>
> The comma at the end is conspicuously absent.
Huh. You're right, the docs don't say anything about commas, even
though the linker supports it. I'll see about adding it to the docs.
> Please either document or fix this. I realize that GNU ld is doing something
> very strange with fillexp, but the fact that a single comma (but not two
> commas!) is legal at the end of an output section description appears to be
> completely undocumented.
Another, documented, way of disambiguating your script is to use
quotes around the special section name "/DISCARD/". In "Output Section
Name", it says: "A section name may consist of any sequence of
characters, but a name which contains any unusual characters such as
commas must be quoted." I guess they don't think '/' is unusual in a
name.
-cary
--
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/16808] ld.gold doesn't know about -Ofast
https://sourceware.org/bugzilla/show_bug.cgi?id=16808 --- Comment #4 from Cary Coutant --- > Is the same true for ld.gold? In which case -O, -Os, -Og, -Ofast are not > implemented and -O1 = -O2 = -O3 = -O4 and so on? At -O1 and above, gold will use a higher compression level with --compress-debug-sections. At -O2 and above, gold will optimize string merge sections by finding strings that are suffixes of longer strings. Currently, that's it. -cary -- 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/16417] executable linked with gold segfaults before main
https://sourceware.org/bugzilla/show_bug.cgi?id=16417 --- Comment #9 from Cary Coutant --- "Normally the linker will add a DT_NEEDED tag for each dynamic library mentioned on the command line, regardless of whether the library is actually needed or not. --as-needed causes a DT_NEEDED tag to only be emitted for a library that at that point in the link [a] satisfies a non-weak undefined symbol reference from a regular object file or, [b] if the library is not found in the DT_NEEDED lists of other libraries, a non-weak undefined symbol reference from another dynamic library." Case [a] is not satisfied here, since there is no reference to libpthread from a regular object file. Case [b] is related to one of the major differences between BFD ld and gold: gold does not track DT_NEEDED lists from shared libraries, so it does not check for this case. I'm still a bit puzzled as to why there's a weak reference to libpthread in the first place. And if there's a weak references, why isn't the code prepared to deal with it remaining unresolved? This seems like an artificial test case to 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/16341] relative paths in ld.script break gold linker
https://sourceware.org/bugzilla/show_bug.cgi?id=16341 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google 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/16794] gold doesn't include the "implicit addend" when processing REL relocations to mergable sections
https://sourceware.org/bugzilla/show_bug.cgi?id=16794 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google 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/16870] Gold internal error with -fpie and -mcmodel=large
https://sourceware.org/bugzilla/show_bug.cgi?id=16870 Cary Coutant changed: What|Removed |Added Assignee|ian at airs dot com|ccoutant at google 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/16870] Gold internal error with -fpie and -mcmodel=large
https://sourceware.org/bugzilla/show_bug.cgi?id=16870 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Cary Coutant --- The problem was a missing break statement when processing an R_X86_64_PLTOFF64 relocation. Fixed on trunk. https://sourceware.org/ml/binutils-cvs/2014-04/msg00141.html -- 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/16870] Gold internal error with -fpie and -mcmodel=large
https://sourceware.org/bugzilla/show_bug.cgi?id=16870 --- Comment #3 from Cary Coutant --- Also fixed on binutils-2.24 branch. -- 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
