[Bug ld/32297] New: sframe: bfd assertion with empty main on IBT enabled system
https://sourceware.org/bugzilla/show_bug.cgi?id=32297
Bug ID: 32297
Summary: sframe: bfd assertion with empty main on IBT enabled
system
Product: binutils
Version: 2.43
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: indu.bhagat at oracle dot com
Target Milestone: ---
On an IBT enabled system, a user reported the following failure:
# cat test-noop.c
int main() {}
# gcc -O2 -Wa,-gsframe -o test-noop test-noop.c
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: BFD
(Gentoo 2.43 p1) 2.43.0 assertion fail
/var/tmp/portage/sys-devel/binutils-2.43/work/binutils-2.43/bfd/elfxx-x86.c:1988
The offending line is:
BFD_ASSERT (ectx);
in _bfd_x86_elf_write_sframe_plt ().
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/32297] sframe: bfd assertion with empty main on IBT enabled system
https://sourceware.org/bugzilla/show_bug.cgi?id=32297
--- Comment #1 from Indu Bhagat ---
A hand-crafted reproducer:
$ cat bar.c
void foo();
unsigned long var;
void test () {
var = (unsigned long)foo;
foo ();
}
$ cat foo.s
.globl foo
foo:
.section.note.GNU-stack,"",@progbits
$ gcc -O2 -Wa,--gsframe -fPIC -c -o bar.o bar.c
$ gcc -O2 -Wa,--gsframe -fPIC -S bar.c
$ ld -shared -z ibtplt -o pltsec.so foo.o bar.o
ld: BFD (GNU Binutils) 2.43.50.20241016 assertion fail
/scratch/ibhagat/BINUTILS-GDB/binutils-gdb/binutils-gdb/bfd/elfxx-x86.c:1990
make: *** [Makefile:23: pltsec.so] Error 1
The above is on trunk, hence a different line number.
The issue seems to be that the implementation in ld has incorrect conditionals
for checking the presence of a .plt.sec, when writing out SFrame for it. As in
the reproducer above, in absence of a .plt.sec, bfd triggers an assertion.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25207] ld: support --image-base= for elf (and -Ttext-segment -z separate-code strangeness)
https://sourceware.org/bugzilla/show_bug.cgi?id=25207 Hakan changed: What|Removed |Added CC||hakancandar at protonmail dot com --- Comment #1 from Hakan --- It has been five years since the initial bug report was filed, and I just reconfirmed with the latest linker that the reported -Ttext-segment behaviour when used with -z separate-code remains the same. Effectively, -Ttext-segment historically and currently stands for specifying the base address of the ELF file - not the first executable segment. Changing the current behaviour of the the option has a high chance of breaking existing projects that use this flag for specifying the base address, so in my opinion it is more clever to preserve it. The LLVM linker has dropped support for -Ttext-segment, and instead suggests specifying --image-base with the following: ~ > ld.lld code.o -Ttext-segment=0x8 ld.lld: error: -Ttext-segment is not supported. Use --image-base if you intend to set the base address All things considered, I suggest preserving the current behaviour of -Ttext-segment for maintaining compatibility with old projects and introducing a new option --image-base for compatibility with the LLVM linker. Here is the patch that introduces the new option --image-base as described. I also added a test case to ensure -Ttext-segment behaviour stays the same. diff --git a/ld/NEWS b/ld/NEWS index 1f14dd6bc77..e9ced61c1db 100644 --- a/ld/NEWS +++ b/ld/NEWS @@ -2,6 +2,9 @@ Changes in 2.44: +* Add --image-base= option to behave the same as -Ttext-segment + for compatibility with LLD. + * Add a "--build-id=xx" option, if built with the xxhash library. This produces a 128-bit hash, 2-4x faster than md5 or sha1. diff --git a/ld/emultempl/elf.em b/ld/emultempl/elf.em index 2e865728587..327f95d62e5 100644 --- a/ld/emultempl/elf.em +++ b/ld/emultempl/elf.em @@ -817,6 +817,7 @@ fragment < should set the first segment address, +# not necessarily the first executable segment. + +#... + LOAD +0x0+ 0x0*12 0x0*12 0x0*[0-9a-f][0-9a-f][0-9a-f] 0x0*[0-9a-f][0-9a-f][0-9a-f] R .* +#pass diff --git a/ld/testsuite/ld-elf/pr25207.s b/ld/testsuite/ld-elf/pr25207.s new file mode 100644 index 000..ffa11bbc550 --- /dev/null +++ b/ld/testsuite/ld-elf/pr25207.s @@ -0,0 +1,8 @@ +.section .text, "ax" + .globl _start +_start: + .space 1 + + .section .rodata + .globl foo +foo: .space 1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32296] sframe: wrong SFrame info for pltN and .plt.sec for -z ibtplt
https://sourceware.org/bugzilla/show_bug.cgi?id=32296 Indu Bhagat changed: What|Removed |Added Assignee|unassigned at sourceware dot org |indu.bhagat at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32297] sframe: bfd assertion with empty main on IBT enabled system
https://sourceware.org/bugzilla/show_bug.cgi?id=32297 Indu Bhagat changed: What|Removed |Added Assignee|unassigned at sourceware dot org |indu.bhagat at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/32252] ./configure produces invalid Makefile
https://sourceware.org/bugzilla/show_bug.cgi?id=32252 --- Comment #7 from dilyan.palauzov at aegee dot org --- It turned out that backslash in echo is not portable, dash behaviour will likely match again bash. I filled https://lists.gnu.org/archive/html/bug-autoconf/2024-10/msg00018.html. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32296] New: sframe: wrong SFrame info for pltN and .plt.sec for -z ibtplt
https://sourceware.org/bugzilla/show_bug.cgi?id=32296 Bug ID: 32296 Summary: sframe: wrong SFrame info for pltN and .plt.sec for -z ibtplt Product: binutils Version: 2.43 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: indu.bhagat at oracle dot com Target Milestone: --- $ cat foo.s .text .p2align 4 .globl bar .type bar, @function bar: .cfi_startproc subq$8, %rsp .cfi_def_cfa_offset 16 callbar@PLT addq$8, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc .size bar, .-bar .section.note.GNU-stack,"",@progbits $ cat bar.s .text .p2align 4 .globl foo .type foo, @function foo: .cfi_startproc call bar@PLT xorl%eax, %eax ret .p2align 4,,10 .p2align 3 .cfi_endproc .size foo, .-foo .section.note.GNU-stack,"",@progbits $ as --gsframe -o foo.o foo.s $ as --gsframe -o bar.o bar.s $ ld -shared -z ibtplt -o pltsec.so foo.o bar.o $ objdump -d pltsec.so ... Disassembly of section .plt: 1000 <.plt>: 1000: ff 35 ea 2f 00 00 push 0x2fea(%rip)# 3ff0 <_GLOBAL_OFFSET_TABLE_+0x8> 1006: ff 25 ec 2f 00 00 jmp*0x2fec(%rip)# 3ff8 <_GLOBAL_OFFSET_TABLE_+0x10> 100c: 0f 1f 40 00 nopl 0x0(%rax) 1010: f3 0f 1e fa endbr64 1014: 68 00 00 00 00 push $0x0 1019: e9 e2 ff ff ff jmp1000 101e: 66 90 xchg %ax,%ax Disassembly of section .plt.sec: 1020 : 1020: f3 0f 1e fa endbr64 1024: ff 25 d6 2f 00 00 jmp*0x2fd6(%rip)# 4000 102a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) $ objdump --sframe pltsec.so func idx [0]: pc = 0x1000, size = 16 bytes STARTPC CFA FPRA 1000 sp+16 u f 1006 sp+24 u f func idx [1]: pc = 0x1010, size = 16 bytes STARTPC[m] CFA FPRA sp+8 u f 000b sp+16 u f func idx [2]: pc = 0x1020, size = 16 bytes STARTPC CFA FPRA 1020 sp+16 u f 1026 sp+24 u f -- You are receiving this mail because: You are on the CC list for the bug.
