aboutsummaryrefslogtreecommitdiff
path: root/libctf/ctf-create.c
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2025-02-28 14:13:02 +0100
committerTom de Vries <tdevries@suse.de>2025-02-28 14:13:02 +0100
commit8cdf110a115c971f3184bbd30f515fd2cd6f72ef (patch)
treefba3f16375fcb1bf5030ae19f4971f5e82592e29 /libctf/ctf-create.c
parentb6fb76ec6ef1e6643c87f29594d76c13aa94d876 (diff)
downloadbinutils-8cdf110a115c971f3184bbd30f515fd2cd6f72ef.zip
binutils-8cdf110a115c971f3184bbd30f515fd2cd6f72ef.tar.gz
binutils-8cdf110a115c971f3184bbd30f515fd2cd6f72ef.tar.bz2
[gdb/testsuite] Fix gdb.base/nostdlib.exp on aarch64
On aarch64-linux, in test-case gdb.base/nostdlib.exp I run into: ... (gdb) continue^M Continuing.^M warning: Temporarily disabling breakpoints for unloaded shared library \ "/lib/ld-linux-aarch64.so.1"^M ^M Breakpoint 2, _start () at nostdlib.c:20^M 20 {^M (gdb) FAIL: $exp: pie=pie: continue to marker ... This happens as follows: - the test-case sets a breakpoint on *_start, - the breakpoint resolves to *_start in the executable, - the executable is started, and the breakpoint resolves to *_start in the dynamic linker, - execution stops at *_start in the dynamic linker, - the test-case issues a continue, expecting to continue to the breakpoint on marker, - while continuing, the dynamic linker is reported as unloaded, - the breakpoint again resolves to *_start in the executable, - execution stops at *_start in the executable, and - the test-case concludes that it failed to "continue to marker". This doesn't happen on x86_64-linux. There, after the executable is started, the breakpoint again resolves to *_start in the exec. This is similar to what happens when printing _start. On aarch64-linux, we print the _start in the dynamic linker: ... $ gdb -q -batch outputs/gdb.base/nostdlib/nostdlib-pie \ -ex "b _start" \ -ex run \ -ex "print _start" \ -ex "info break" Breakpoint 1 at 0x2bc: file nostdlib.c, line 23. Breakpoint 1.2, _start () at ../sysdeps/aarch64/dl-start.S:22 22 ENTRY (_start) $1 = {void (void)} 0xfffff7fd6ac0 <_start> Num Type Disp Enb Address What 1 breakpoint keep y <MULTIPLE> breakpoint already hit 1 time 1.1 y 0x0000aaaaaaaa02bc in _start at nostdlib.c:23 1.2 y 0x0000fffff7fd6ac0 in _start at dl-start.S:22 ... On x86_64-linux, we print the _start in the exec: ... Breakpoint 1 at 0x2c5: file nostdlib.c, line 23. Breakpoint 1.2, 0x00007ffff7fe4f00 in _start () from \ /lib64/ld-linux-x86-64.so.2 $1 = {void (void)} 0x5555555542c1 <_start> Num Type Disp Enb Address What 1 breakpoint keep y <MULTIPLE> breakpoint already hit 1 time 1.1 y 0x00005555555542c5 in _start at nostdlib.c:23 1.2 y 0x00007ffff7fe4f00 <_start> ... The difference may be down to the availability of debug info for the _start in the dynamic linker. Finally, the described scenario on aarch64-linux is not deterministic. The behavior depends on the dynamic linker being reported as unloaded, which has been classified as a GLIBC bug, so that might get fixed. Ideally this test-case would stop at both *_start in the executable and the dynamic linker, but in absense of a way to specify this reliably (see PR32748), fix this by making this a temporary breakpoint, ensuring that the breakpoint will only trigger once. Approved-by: Kevin Buettner <kevinb@redhat.com> PR testsuite/32743 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32743
Diffstat (limited to 'libctf/ctf-create.c')
0 files changed, 0 insertions, 0 deletions