[Bug ld/20800] New: BFD Linker failing (unresolvable R_X86_64_PLTOFF64) with -mcmodel=large and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=20800
Bug ID: 20800
Summary: BFD Linker failing (unresolvable R_X86_64_PLTOFF64)
with -mcmodel=large and --start-group
Product: binutils
Version: 2.27
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: keno at juliacomputing dot com
Target Milestone: ---
Reduced from UML Linux Kernel build. ld.bfd fails with the following error,
ld.gold seems to work fine:
```
keno@anubis:~/linkerbug$ cat test.c
#include
int main(void) {
printf("Hello World");
}
keno@anubis:~/linkerbug$ gcc -shared -mcmodel=large -fno-builtin -c test.c
keno@anubis:~/linkerbug$ gcc -Wl,-rpath,/lib64 -m64 -Wl,--start-group test.o
-Wl,--end-group
/usr/bin/ld: test.o(.text+0x36): unresolvable R_X86_64_PLTOFF64 relocation
against symbol `printf@@GLIBC_2.2.5'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
keno@anubis:~/linkerbug$ sudo cp -a /usr/bin/ld.gold /usr/bin/ld
keno@anubis:~/linkerbug$ gcc -Wl,-rpath,/lib64 -m64 -Wl,--start-group test.o
-Wl,--end-group
keno@anubis:~/linkerbug$ #worked
```
--
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/20767] empty archive input causes "internal error in target, at ../../gold/parameters.h:105"
https://sourceware.org/bugzilla/show_bug.cgi?id=20767 Keno Fischer changed: What|Removed |Added CC||keno at juliacomputing 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 ld/20800] BFD Linker failing (unresolvable R_X86_64_PLTOFF64) with -mcmodel=large and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=20800 --- Comment #2 from Keno Fischer --- This is on stock Ubuntu 16.10. Try adding `-fPIE` to the compile invocation maybe? I know Debian recently switched that on by default. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20800] BFD Linker failing (unresolvable R_X86_64_PLTOFF64) with -mcmodel=large and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=20800 --- Comment #4 from Keno Fischer --- Attaching my test.o here. Maybe it's a compiler problem. What version of ld are you using? Maybe it's already fixed? I have: ``` ld --version GNU ld (GNU Binutils for Ubuntu) 2.27 Copyright (C) 2016 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. ``` I'd also be happy to give you SSH access to this machine. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20800] BFD Linker failing (unresolvable R_X86_64_PLTOFF64) with -mcmodel=large and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=20800 --- Comment #5 from Keno Fischer --- Created attachment 9625 --> https://sourceware.org/bugzilla/attachment.cgi?id=9625&action=edit My test.o -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20800] BFD Linker failing (unresolvable R_X86_64_PLTOFF64) with -mcmodel=large and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=20800 --- Comment #11 from Keno Fischer --- Awesome, thank you so much! -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20830] New: .plt.got section is lacking unwind info
https://sourceware.org/bugzilla/show_bug.cgi?id=20830 Bug ID: 20830 Summary: .plt.got section is lacking unwind info Product: binutils Version: 2.27 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: keno at juliacomputing dot com Target Milestone: --- Consider a simple executable, where one function needs both a GOT and PLT entry, e.g. ``` .text .globl _start .type _start, @function _start: .cfi_startproc .cfi_undefined %rip movq func1@GOTPCREL(%rip), %rax callq func1@plt callq func2@plt movq func3@GOTPCREL(%rip), %rax hlt .cfi_endproc ``` Now, ld is smart enough to combine the vanilla GOT entry and that required by the PLT, placing a different kind of PLT stub in the `.plt.got` section: ``` gcc -c plt.S ld -o plt plt.o plt-dyn.so ; plt-dyn is just some shared library that defines these symbols objdump -d plt plt: file format elf64-x86-64 Disassembly of section .plt: 00400300 : 400300: ff 35 02 0d 20 00 pushq 0x200d02(%rip)# 601008 <_GLOBAL_OFFSET_TABLE_+0x8> 400306: ff 25 04 0d 20 00 jmpq *0x200d04(%rip)# 601010 <_GLOBAL_OFFSET_TABLE_+0x10> 40030c: 0f 1f 40 00 nopl 0x0(%rax) 00400310 : 400310: ff 25 02 0d 20 00 jmpq *0x200d02(%rip)# 601018 <_GLOBAL_OFFSET_TABLE_+0x18> 400316: 68 00 00 00 00 pushq $0x0 40031b: e9 e0 ff ff ff jmpq 400300 Disassembly of section .plt.got: 00400320 <.plt.got>: 400320: ff 25 d2 0c 20 00 jmpq *0x200cd2(%rip)# 600ff8 <_DYNAMIC+0x148> 400326: 66 90 xchg %ax,%ax Disassembly of section .text: 00400328 <_start>: 400328: 48 8b 05 c9 0c 20 00mov0x200cc9(%rip),%rax# 600ff8 <_DYNAMIC+0x148> 40032f: e8 ec ff ff ff callq 400320 400334: e8 d7 ff ff ff callq 400310 400339: 48 8b 05 b0 0c 20 00mov0x200cb0(%rip),%rax# 600ff0 <_DYNAMIC+0x140> 400340: f4 hlt ``` which is very nice. Unfortunately, unlike the for .plt section, ld does not create an FDE for the .plt.got section: ``` objdump --dwarf=frames a.out: file format elf64-x86-64 Contents of the .eh_frame section: 0014 CIE Version: 1 Augmentation: "zR" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 1b DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_undefined: r16 (rip) 0018 0014 001c FDE cie= pc=00400328..00400341 DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop 0030 0014 CIE Version: 1 Augmentation: "zR" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 1b DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_nop DW_CFA_nop 0048 0024 001c FDE cie=0030 pc=00400300..00400320 DW_CFA_def_cfa_offset: 16 DW_CFA_advance_loc: 6 to 00400306 DW_CFA_def_cfa_offset: 24 DW_CFA_advance_loc: 10 to 00400310 DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 8; DW_OP_breg16 (rip): 0; DW_OP_lit15; DW_OP_and; DW_OP_lit11; DW_OP_ge; DW_OP_lit3; DW_OP_shl; DW_OP_plus) DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop ``` Of course the .plt.got needs nothing fancy, just a simple DW_CFA_nop with the same CIE as the .plt section would be sufficient. I should note that most debuggers still get this right due to heuristics. However, there are unwinders (e.g. in language runtimes), that purely rely on .eh_frame, so it would be nice if the linker created the appropriate FDE. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20830] .plt.got section is lacking unwind info
https://sourceware.org/bugzilla/show_bug.cgi?id=20830 --- Comment #3 from Keno Fischer --- Apologies for the delay. The patch works for me and fixes the cases I saw. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20830] .plt.got section is lacking unwind info
https://sourceware.org/bugzilla/show_bug.cgi?id=20830 --- Comment #5 from Keno Fischer --- It causes runtime failures in exactly the same cases as missing `.plt` info would: Asynchronous unwinds that happen to originate in .plt stubs. This bug was filed as a result of me working through all the cases where we failed to properly unwind. I could see the stance that it's not the linker's job to add unwind info, but in that case unwinders would have hacked that case into their algorithm. However, since the linker does provide unwind info for the .plt, it seems important that it should provide unwind info for all of its generated stubs. The current situation causes subtle unwind failures (admittedly rare, because triggering it requires being lucky as well as using asynchronous unwind, which most people don't because until recently most non-MSVC compilers weren't particularly good at this either). I'm not really sure what to provide you as a test case here, other than to say, take any program that triggers this optimization, interrupt it at random points and try to unwind with say libunwind (or any of the other unwinders that rely on unwind info instead of assembly profiling). It's a little hard to find a current real-world application that relies on asynchronous unwind for correctness (other than correct stack traces and other debug info, etc.), but that's not because people wouldn't find it useful, but rather because of problems like this one (though to be clear compilers generating incorrect unwind info is by far a bigger problem - though there's been working on fixing that) that have made it impossible to do so in the past. I'm hoping to systematically track down all of these issues, such that maybe in the future we can actually rely on being able to properly unwind as opposed to the "best effort" kind of situation we have now. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20830] .plt.got section is lacking unwind info
https://sourceware.org/bugzilla/show_bug.cgi?id=20830 --- Comment #7 from Keno Fischer --- In an idealized world, yes, we could assume a default unwind rule if none is found, but in the real world, it is safer to just terminate the unwind when no unwind info is present (because more often than not it's broken compiler or somebody forgot to add CFI info to their assembly). Also, note that it's not just the nop, but also the instructions in the CIE that matter. If you are concerned about code size bloat, perhaps the .plt FDE could simply be extended to also cover the .plt.got section in the common case that they are right next to each other (hell, there's enough padding there right now that for small binaries it wouldn't change the code size at all)? Also, it seems like applications which don't care about unwinding at all should simply strip out .eh_frame entirely. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20830] .plt.got section is lacking unwind info
https://sourceware.org/bugzilla/show_bug.cgi?id=20830 --- Comment #8 from Keno Fischer --- Bump on this. I would still very much like to see this applied. -- 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/28699] New: Bad interaction between .loc, .byte causes incorrect DWARF line table, causes corruption under gdb
https://sourceware.org/bugzilla/show_bug.cgi?id=28699
Bug ID: 28699
Summary: Bad interaction between .loc, .byte causes incorrect
DWARF line table, causes corruption under gdb
Product: binutils
Version: 2.38 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: keno at juliacomputing dot com
Target Milestone: ---
Consider the following code which is reduced from wine:
minimal.c
```
void *wine_ntdll_get_thread_data() {
void *teb;
__asm__(".byte 0x65\n\tmovq (0x30),%0" : "=r" (teb));
return teb;
}
```
gcc -g3 -S -o minimal.S minimal.c
```
[snip]
.loc 1 3 5
#APP
# 3 "minimal.c" 1
.byte 0x65
movq (0x30),%rax
# 0 "" 2
#NO_APP
[snip]
```
$ as minimal.S -o minimal.o
objdump -d minimal.o
```
Disassembly of section .text:
:
0: f3 0f 1e fa endbr64
4: 55 push %rbp
5: 48 89 e5mov%rsp,%rbp
8: 65 48 8b 04 25 30 00mov%gs:0x30,%rax
f: 00 00
11: 48 89 45 f8 mov%rax,-0x8(%rbp)
15: 48 8b 45 f8 mov-0x8(%rbp),%rax
19: 5d pop%rbp
1a: c3 retq
```
objdump --dwarf=line minimal.o
```
Line Number Statements:
[0x0048] Set column to 36
[0x004a] Extended opcode 2: set Address to 0x0
[0x0055] Copy
[0x0056] Set column to 5
[0x0058] Special opcode 133: advance Address by 9 to 0x9 and Line by 2
to 3
[0x0059] Set column to 12
[0x005b] Special opcode 174: advance Address by 12 to 0x15 and Line by 1
to 4
[0x005c] Set column to 1
[0x005e] Special opcode 62: advance Address by 4 to 0x19 and Line by 1
to 5
[0x005f] Advance PC by 2 to 0x1b
[0x0061] Extended opcode 1: End of Sequence
```
Note that the line table has an entry at address `0x9` which is
in the middle of the instruction at `0x8`. Because of this,
GDB will set a breakpoint there and subsequently execute
the instruction without the gs prefix causing crashes.
I believe GAS is wrong here to have put 0x9 as the line
table entry and instead should have put it before the `.byte`
at 0x8.
--
You are receiving this mail because:
You are on the CC list for the bug.
