aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-cmd.c
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2025-05-02 16:48:14 +0200
committerTom de Vries <tdevries@suse.de>2025-05-02 16:48:14 +0200
commitb381c2381c5b069c3f2e969334368c4d4fdf25be (patch)
tree586920e59323a1b523f9b70cd86eefa2b00aa5d9 /gdb/python/py-cmd.c
parentee471175031e58c0b87961992a9fa537e557074a (diff)
downloadbinutils-b381c2381c5b069c3f2e969334368c4d4fdf25be.zip
binutils-b381c2381c5b069c3f2e969334368c4d4fdf25be.tar.gz
binutils-b381c2381c5b069c3f2e969334368c4d4fdf25be.tar.bz2
[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
Diffstat (limited to 'gdb/python/py-cmd.c')
0 files changed, 0 insertions, 0 deletions