]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
[gdb/testsuite] Fix gdb.base/step-over-syscall.exp with glibc 2.41
authorTom de Vries <tdevries@suse.de>
Tue, 11 Mar 2025 08:38:50 +0000 (09:38 +0100)
committerTom de Vries <tdevries@suse.de>
Tue, 11 Mar 2025 08:38:50 +0000 (09:38 +0100)
commit674d48567300d29db5f9759a78d987333b914d68
treeef40103b6fce57799d9bb9b43d33df6ed4a3f660
parent827f39f7e5d0c208275482cec979b9b5592c4aa8
[gdb/testsuite] Fix gdb.base/step-over-syscall.exp with glibc 2.41

On openSUSE Tumbleweed, with glibc 2.41, when running test-case
gdb.base/step-over-syscall.exp I run into:
...
(gdb) stepi^M
0x00007ffff7cfd09b in __abort_lock_rdlock () from /lib64/libc.so.6^M
1: x/i $pc^M
=> 0x7ffff7cfd09b <__abort_lock_rdlock+29>:     syscall^M
(gdb) p $eax^M
$1 = 14^M
(gdb) FAIL: $exp: fork: displaced=off: syscall number matches
FAIL: $exp: fork: displaced=off: find syscall insn in fork (timeout)
...

We're stepi-ing through fork trying to find the fork syscall, but encounter
another syscall.

The test-case attempts to handle this:
...
      gdb_test_multiple "stepi" "find syscall insn in $syscall" {
            -re ".*$syscall_insn.*$gdb_prompt $" {
                # Is the syscall number the correct one?
if {[syscall_number_matches $syscall]} {
                    pass $gdb_test_name
                } else {
    exp_continue
                }
            }
            -re "x/i .*=>.*\r\n$gdb_prompt $" {
                incr steps
                if {$steps == $max_steps} {
                    fail $gdb_test_name
                } else {
                    send_gdb "stepi\n"
                    exp_continue
                }
            }
        }
...
but fails to do so because it issues an exp_continue without issuing a new
stepi command, and consequently the "find syscall insn in fork" test times
out.

Also, the call to syscall_number_matches produces a PASS or FAIL, so skipping
one syscall would produce:
...
FAIL: $exp: fork: displaced=off: syscall number matches
PASS: $exp: fork: displaced=off: syscall number matches
DUPLICATE: $exp: fork: displaced=off: syscall number matches
...

Fix this by:
- not producing PASS or FAIL in syscall_number_matches, and
- issuing stepi when encountering another syscall.

While we're at it, fix indentation in syscall_number_matches.

Tested on x86_64-linux, specifically:
- openSUSE Tumbleweed (glibc 2.41), and
- openSUSE Leap 15.6 (glibc 2.38).

PR testsuite/32780
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32780
gdb/testsuite/gdb.base/step-over-syscall.exp