]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
[gdb/testsuite] Fix gdb.reverse/time-reverse.exp timeout
authorTom de Vries <tdevries@suse.de>
Fri, 2 May 2025 14:48:14 +0000 (16:48 +0200)
committerTom de Vries <tdevries@suse.de>
Fri, 2 May 2025 14:48:14 +0000 (16:48 +0200)
commitb381c2381c5b069c3f2e969334368c4d4fdf25be
tree586920e59323a1b523f9b70cd86eefa2b00aa5d9
parentee471175031e58c0b87961992a9fa537e557074a
[gdb/testsuite] Fix gdb.reverse/time-reverse.exp timeout

After building gdb with "-O0 -g -fsanitize=thread" on aarch64-linux, with
test-case gdb.reverse/time-reverse.exp I run into:
...
(gdb) continue^M
Continuing.^M
FAIL: $exp: mode=c: continue to breakpoint: marker2 (timeout)
...

The problem is that instruction stepping gets stuck in a loop with this call
stack: time -> __GI___clock_gettime -> __kernel_clock_gettime ->
__cvdso_clock_gettime.

This is not specific to fsanitize=thread, it just makes gdb slow, which makes
instruction stepping slow, which results in the application getting stuck.

I ran into this as well with a regular gdb build on a 32-bit i686 laptop with
1GB of memory, an inherently slow setup.  In that instance, I was able to
observe that the loop we're stuck in is the outer loop in do_coarse in linux
kernel source lib/vdso/gettimeofday.c.

Fix this by setting "record full insn-number-max" to 2000, and handling
running into the limit.

Initially I tried the approach of using "stepi 2000" instead of continue, but
that made the issue more likely to show up (for instance, I observed it after
building gdb with -O0 on aarch64-linux).

Tested on aarch64-linux.

Approved-By: Guinevere Larsen <guinevere@redhat.com>
PR testsuite/32678
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32678
gdb/testsuite/gdb.reverse/time-reverse.exp