binutils-gdb/gdb/testsuite/gdb.base/longjmp.exp

228 lines
6.7 KiB
Text
Raw Normal View History

# Copyright 2008-2023 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
# Test support for stepping over longjmp.
#
standard_testfile .c
if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug nowarnings}] != "" } {
Fixup testcases outputting own name as a test name and standardize failed compilation messages Changes in v3: - Adjusted some testcases where the message "failed to compile" was not unique. Changes in v2: - Addressed comments from reviewers. - Fixed spurious whitespaces. - Changed compilation failure messages that included source/binary paths to ones that are short and deterministic. --- Another bit of cleanup to the testsuite. We have a number of tests that are not honoring the rule of not outputting their own name as a test name. I fixed up all the offenders i could find with the following regular expression: "(xfail|kfail|kpass|fail|pass|unsupported|untested) ([A-Za-z0-9]+|\\\$(.)*testfile(.)*)\.exp$" gdb/testsuite/ChangeLog: 2016-12-01 Luis Machado <lgustavo@codesourcery.com> Fix test names and standardize compilation error messages throughout the following files: * gdb.ada/start.exp * gdb.arch/alpha-step.exp * gdb.arch/e500-prologue.exp * gdb.arch/ftrace-insn-reloc.exp * gdb.arch/gdb1291.exp * gdb.arch/gdb1431.exp * gdb.arch/gdb1558.exp * gdb.arch/i386-dr3-watch.exp * gdb.arch/i386-sse-stack-align.exp * gdb.arch/ia64-breakpoint-shadow.exp * gdb.arch/pa-nullify.exp * gdb.arch/powerpc-aix-prologue.exp * gdb.arch/thumb-bx-pc.exp * gdb.base/annota1.exp * gdb.base/annota3.exp * gdb.base/arrayidx.exp * gdb.base/assign.exp * gdb.base/attach.exp * gdb.base/auxv.exp * gdb.base/bang.exp * gdb.base/bfp-test.exp * gdb.base/bigcore.exp * gdb.base/bitfields2.exp * gdb.base/break-fun-addr.exp * gdb.base/break-probes.exp * gdb.base/call-rt-st.exp * gdb.base/callexit.exp * gdb.base/catch-fork-kill.exp * gdb.base/charset.exp * gdb.base/checkpoint.exp * gdb.base/comprdebug.exp * gdb.base/constvars.exp * gdb.base/coredump-filter.exp * gdb.base/cursal.exp * gdb.base/cvexpr.exp * gdb.base/detach.exp * gdb.base/display.exp * gdb.base/dmsym.exp * gdb.base/dprintf-pending.exp * gdb.base/dso2dso.exp * gdb.base/dtrace-probe.exp * gdb.base/dump.exp * gdb.base/enum_cond.exp * gdb.base/exe-lock.exp * gdb.base/exec-invalid-sysroot.exp * gdb.base/execl-update-breakpoints.exp * gdb.base/exprs.exp * gdb.base/fileio.exp * gdb.base/find.exp * gdb.base/finish.exp * gdb.base/fixsection.exp * gdb.base/foll-vfork.exp * gdb.base/frame-args.exp * gdb.base/gcore.exp * gdb.base/gdb1250.exp * gdb.base/global-var-nested-by-dso.exp * gdb.base/gnu-ifunc.exp * gdb.base/hashline1.exp * gdb.base/hashline2.exp * gdb.base/hashline3.exp * gdb.base/hbreak-in-shr-unsupported.exp * gdb.base/huge.exp * gdb.base/infcall-input.exp * gdb.base/info-fun.exp * gdb.base/info-shared.exp * gdb.base/jit-simple.exp * gdb.base/jit-so.exp * gdb.base/jit.exp * gdb.base/jump.exp * gdb.base/label.exp * gdb.base/lineinc.exp * gdb.base/logical.exp * gdb.base/longjmp.exp * gdb.base/macscp.exp * gdb.base/miscexprs.exp * gdb.base/new-ui-echo.exp * gdb.base/new-ui-pending-input.exp * gdb.base/new-ui.exp * gdb.base/nodebug.exp * gdb.base/nofield.exp * gdb.base/offsets.exp * gdb.base/overlays.exp * gdb.base/pending.exp * gdb.base/pointers.exp * gdb.base/pr11022.exp * gdb.base/printcmds.exp * gdb.base/prologue.exp * gdb.base/ptr-typedef.exp * gdb.base/realname-expand.exp * gdb.base/relativedebug.exp * gdb.base/relocate.exp * gdb.base/remote.exp * gdb.base/reread.exp * gdb.base/return2.exp * gdb.base/savedregs.exp * gdb.base/sep.exp * gdb.base/sepdebug.exp * gdb.base/sepsymtab.exp * gdb.base/set-inferior-tty.exp * gdb.base/setshow.exp * gdb.base/shlib-call.exp * gdb.base/sigaltstack.exp * gdb.base/siginfo-addr.exp * gdb.base/signals.exp * gdb.base/signull.exp * gdb.base/sigrepeat.exp * gdb.base/so-impl-ld.exp * gdb.base/solib-display.exp * gdb.base/solib-overlap.exp * gdb.base/solib-search.exp * gdb.base/solib-symbol.exp * gdb.base/structs.exp * gdb.base/structs2.exp * gdb.base/symtab-search-order.exp * gdb.base/twice.exp * gdb.base/unload.exp * gdb.base/varargs.exp * gdb.base/watchpoint-solib.exp * gdb.base/watchpoint.exp * gdb.base/whatis.exp * gdb.base/wrong_frame_bt_full.exp * gdb.btrace/dlopen.exp * gdb.cell/ea-standalone.exp * gdb.cell/ea-test.exp * gdb.cp/dispcxx.exp * gdb.cp/gdb2384.exp * gdb.cp/method2.exp * gdb.cp/nextoverthrow.exp * gdb.cp/pr10728.exp * gdb.disasm/am33.exp * gdb.disasm/h8300s.exp * gdb.disasm/mn10300.exp * gdb.disasm/sh3.exp * gdb.dwarf2/dw2-dir-file-name.exp * gdb.fortran/complex.exp * gdb.fortran/library-module.exp * gdb.guile/scm-pretty-print.exp * gdb.guile/scm-symbol.exp * gdb.guile/scm-type.exp * gdb.guile/scm-value.exp * gdb.linespec/linespec.exp * gdb.mi/gdb701.exp * gdb.mi/gdb792.exp * gdb.mi/mi-breakpoint-changed.exp * gdb.mi/mi-dprintf-pending.exp * gdb.mi/mi-dprintf.exp * gdb.mi/mi-exit-code.exp * gdb.mi/mi-pending.exp * gdb.mi/mi-solib.exp * gdb.mi/new-ui-mi-sync.exp * gdb.mi/pr11022.exp * gdb.mi/user-selected-context-sync.exp * gdb.opt/solib-intra-step.exp * gdb.python/py-events.exp * gdb.python/py-finish-breakpoint.exp * gdb.python/py-mi.exp * gdb.python/py-prettyprint.exp * gdb.python/py-shared.exp * gdb.python/py-symbol.exp * gdb.python/py-template.exp * gdb.python/py-type.exp * gdb.python/py-value.exp * gdb.reverse/solib-precsave.exp * gdb.reverse/solib-reverse.exp * gdb.server/solib-list.exp * gdb.stabs/weird.exp * gdb.threads/reconnect-signal.exp * gdb.threads/stepi-random-signal.exp * gdb.trace/actions.exp * gdb.trace/ax.exp * gdb.trace/backtrace.exp * gdb.trace/change-loc.exp * gdb.trace/deltrace.exp * gdb.trace/ftrace-lock.exp * gdb.trace/ftrace.exp * gdb.trace/infotrace.exp * gdb.trace/mi-tracepoint-changed.exp * gdb.trace/packetlen.exp * gdb.trace/passcount.exp * gdb.trace/pending.exp * gdb.trace/range-stepping.exp * gdb.trace/report.exp * gdb.trace/stap-trace.exp * gdb.trace/tfind.exp * gdb.trace/trace-break.exp * gdb.trace/trace-condition.exp * gdb.trace/trace-enable-disable.exp * gdb.trace/trace-mt.exp * gdb.trace/tracecmd.exp * gdb.trace/tspeed.exp * gdb.trace/tsv.exp * lib/perftest.exp
2016-12-01 14:47:50 -06:00
untested "failed to compile"
return -1
}
proc do_test { with_probes } {
clean_restart ${::binfile}
if { !$with_probes } {
gdb_test "maint ignore-probes libc ^longjmp$"
}
if {![runto_main]} {
return 0
}
# With a libc with probes, all tests should pass.
#
# Without probes, we can still set a break on longjmp, but getting the longjmp
# target may not work, in the following cases:
# - gdbarch_get_longjmp_target_p (gdbarch) == 0: not implemented.
# - gdbarch_get_longjmp_target (gdbarch) == 0: for instance on amd64 if
# tdep->jb_pc_offset == -1.
# - gdbarch_get_longjmp_target (gdbarch) != 0: if we have a glibc with
# pointer mangling ( https://sourceware.org/glibc/wiki/PointerEncryption )
# then we retrieve a mangled longjmp target that needs to be demangled.
# For instance on amd64 with target board unix/-m32.
#
# Pointer demangling is currently not implemented for any target.
# For the amd64 case, this would require copying for instance this:
# 48 c1 ca 11 ror $0x11,%rdx
# 64 48 33 14 25 30 00 xor %fs:0x30,%rdx
# into a scratch space, save the register set, set %rdx to the mangled
# longjmp target, displaced-step through the two insn and read the
# demangled longjmp target from %rdx, and restore the register set.
#
# The failure mode in the first two cases is that the next degrades into a
# continue. The failure mode in the latter case is a failure to set a
# breakpoint (matched by re_cannot_insert_bp) and a stop in longjmp.
#
# We detect the different failure modes and kfail these.
set have_longjmp_probe 0
gdb_test_multiple "info probes stap libc ^longjmp$" "" {
-re -wrap "No probes matched\\." {
pass $gdb_test_name
}
-re -wrap "\r\nstap\[ \t\]+libc\[ \t\]+longjmp\[ \t\]+.*" {
pass $gdb_test_name
set have_longjmp_probe 1
}
}
if { $with_probes } {
if { !$have_longjmp_probe } {
unsupported "longjmp probe required"
return
}
} else {
gdb_assert { !$have_longjmp_probe }
}
[gdb/testsuite] Fix linespec ambiguity in gdb.base/longjmp.exp PR testsuite/30103 reports the following failure on aarch64-linux (ubuntu 22.04): ... (gdb) PASS: gdb.base/longjmp.exp: with_probes=0: pattern 1: next to longjmp next warning: Breakpoint address adjusted from 0x83dc305fef755015 to \ 0xffdc305fef755015. Warning: Cannot insert breakpoint 0. Cannot access memory at address 0xffdc305fef755015 __libc_siglongjmp (env=0xaaaaaaab1018 <env>, val=1) at ./setjmp/longjmp.c:30 30 } (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) delete breakpoints Delete all breakpoints? (y or n) y (gdb) info breakpoints No breakpoints or watchpoints. (gdb) break 63 No line 63 in the current file. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint \ at pattern start (got interactive prompt) ... The test-case intends to set the breakpoint on line number 63 in gdb.base/longjmp.c. It tries to do so by specifying "break 63", which specifies a line in the "current source file". Due to the KFAIL PR, gdb stopped in __libc_siglongjmp, and because of presence of debug info, the "current source file" becomes glibc's ./setjmp/longjmp.c. Consequently, setting the breakpoint fails. Fix this by adding a $subdir/$srcfile: prefix to the breakpoint linespecs. I've managed to reproduce the FAIL on x86_64/-m32, by installing the glibc-32bit-debuginfo package. This allowed me to confirm the "current source file" that is used: ... (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) info source^M Current source file is ../setjmp/longjmp.c^M ... Tested on x86_64-linux, target boards unix/{-m64,-m32}. Reported-By: Luis Machado <luis.machado@arm.com> Reviewed-By: Tom Tromey <tom@tromey.com> PR testsuite/30103 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30103
2023-02-10 15:58:00 +01:00
# When using these line numbers in break linespecs, prefix each of these
# with "$subdir/$srcfile:" to avoid referring to a glibc file when stopped
# in __libc_siglongjmp or similar.
set bp_miss_step_1 [gdb_get_line_number "miss_step_1"]
set bp_miss_step_2 [gdb_get_line_number "miss_step_2"]
set bp_start_test_1 [gdb_get_line_number "patt1"]
set bp_start_test_2 [gdb_get_line_number "patt2"]
set bp_start_test_3 [gdb_get_line_number "patt3"]
set re_cannot_insert_bp \
[multi_line \
"Warning:" \
"Cannot insert breakpoint $::decimal\\." \
"Cannot access memory at address $::hex"]
#
# Pattern 1 - simple longjmp.
#
with_test_prefix "pattern 1" {
with_test_prefix setup {
delete_breakpoints
[gdb/testsuite] Fix linespec ambiguity in gdb.base/longjmp.exp PR testsuite/30103 reports the following failure on aarch64-linux (ubuntu 22.04): ... (gdb) PASS: gdb.base/longjmp.exp: with_probes=0: pattern 1: next to longjmp next warning: Breakpoint address adjusted from 0x83dc305fef755015 to \ 0xffdc305fef755015. Warning: Cannot insert breakpoint 0. Cannot access memory at address 0xffdc305fef755015 __libc_siglongjmp (env=0xaaaaaaab1018 <env>, val=1) at ./setjmp/longjmp.c:30 30 } (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) delete breakpoints Delete all breakpoints? (y or n) y (gdb) info breakpoints No breakpoints or watchpoints. (gdb) break 63 No line 63 in the current file. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint \ at pattern start (got interactive prompt) ... The test-case intends to set the breakpoint on line number 63 in gdb.base/longjmp.c. It tries to do so by specifying "break 63", which specifies a line in the "current source file". Due to the KFAIL PR, gdb stopped in __libc_siglongjmp, and because of presence of debug info, the "current source file" becomes glibc's ./setjmp/longjmp.c. Consequently, setting the breakpoint fails. Fix this by adding a $subdir/$srcfile: prefix to the breakpoint linespecs. I've managed to reproduce the FAIL on x86_64/-m32, by installing the glibc-32bit-debuginfo package. This allowed me to confirm the "current source file" that is used: ... (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) info source^M Current source file is ../setjmp/longjmp.c^M ... Tested on x86_64-linux, target boards unix/{-m64,-m32}. Reported-By: Luis Machado <luis.machado@arm.com> Reviewed-By: Tom Tromey <tom@tromey.com> PR testsuite/30103 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30103
2023-02-10 15:58:00 +01:00
gdb_test "break $::subdir/$::srcfile:$bp_start_test_1" \
"Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_1.*" \
"breakpoint at pattern start"
gdb_test "continue" "patt1.*" "continue to breakpoint at pattern start"
# set safe-net break
[gdb/testsuite] Fix linespec ambiguity in gdb.base/longjmp.exp PR testsuite/30103 reports the following failure on aarch64-linux (ubuntu 22.04): ... (gdb) PASS: gdb.base/longjmp.exp: with_probes=0: pattern 1: next to longjmp next warning: Breakpoint address adjusted from 0x83dc305fef755015 to \ 0xffdc305fef755015. Warning: Cannot insert breakpoint 0. Cannot access memory at address 0xffdc305fef755015 __libc_siglongjmp (env=0xaaaaaaab1018 <env>, val=1) at ./setjmp/longjmp.c:30 30 } (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) delete breakpoints Delete all breakpoints? (y or n) y (gdb) info breakpoints No breakpoints or watchpoints. (gdb) break 63 No line 63 in the current file. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint \ at pattern start (got interactive prompt) ... The test-case intends to set the breakpoint on line number 63 in gdb.base/longjmp.c. It tries to do so by specifying "break 63", which specifies a line in the "current source file". Due to the KFAIL PR, gdb stopped in __libc_siglongjmp, and because of presence of debug info, the "current source file" becomes glibc's ./setjmp/longjmp.c. Consequently, setting the breakpoint fails. Fix this by adding a $subdir/$srcfile: prefix to the breakpoint linespecs. I've managed to reproduce the FAIL on x86_64/-m32, by installing the glibc-32bit-debuginfo package. This allowed me to confirm the "current source file" that is used: ... (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) info source^M Current source file is ../setjmp/longjmp.c^M ... Tested on x86_64-linux, target boards unix/{-m64,-m32}. Reported-By: Luis Machado <luis.machado@arm.com> Reviewed-By: Tom Tromey <tom@tromey.com> PR testsuite/30103 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30103
2023-02-10 15:58:00 +01:00
gdb_test "break $::subdir/$::srcfile:$bp_miss_step_1" \
"Breakpoint.*at.* file .*$::srcfile, line.*$bp_miss_step_1.*" \
"breakpoint at safety net"
}
gdb_test "next" "longjmps\\+\\+;.*" "next over setjmp"
gdb_test "next" "longjmp \\(env, 1\\);.*" "next to longjmp"
set msg "next over longjmp"
gdb_test_multiple "next" $msg {
-re ".*patt1.*$::gdb_prompt $" {
pass $msg
gdb_test "next" "resumes\\+\\+.*" "next into else block"
gdb_test "next" "miss_step_1.*" "next into safety net"
}
-re "miss_step_1.*$::gdb_prompt $" {
if { $have_longjmp_probe } {
fail $gdb_test_name
} else {
kfail $gdb_test_name "gdb/26967"
}
}
-re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
if { $have_longjmp_probe } {
fail $gdb_test_name
} else {
kfail $gdb_test_name "gdb/26967"
}
}
}
}
#
# Pattern 2 - longjmp from an inner function.
#
with_test_prefix "pattern 2" {
with_test_prefix setup {
delete_breakpoints
[gdb/testsuite] Fix linespec ambiguity in gdb.base/longjmp.exp PR testsuite/30103 reports the following failure on aarch64-linux (ubuntu 22.04): ... (gdb) PASS: gdb.base/longjmp.exp: with_probes=0: pattern 1: next to longjmp next warning: Breakpoint address adjusted from 0x83dc305fef755015 to \ 0xffdc305fef755015. Warning: Cannot insert breakpoint 0. Cannot access memory at address 0xffdc305fef755015 __libc_siglongjmp (env=0xaaaaaaab1018 <env>, val=1) at ./setjmp/longjmp.c:30 30 } (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) delete breakpoints Delete all breakpoints? (y or n) y (gdb) info breakpoints No breakpoints or watchpoints. (gdb) break 63 No line 63 in the current file. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint \ at pattern start (got interactive prompt) ... The test-case intends to set the breakpoint on line number 63 in gdb.base/longjmp.c. It tries to do so by specifying "break 63", which specifies a line in the "current source file". Due to the KFAIL PR, gdb stopped in __libc_siglongjmp, and because of presence of debug info, the "current source file" becomes glibc's ./setjmp/longjmp.c. Consequently, setting the breakpoint fails. Fix this by adding a $subdir/$srcfile: prefix to the breakpoint linespecs. I've managed to reproduce the FAIL on x86_64/-m32, by installing the glibc-32bit-debuginfo package. This allowed me to confirm the "current source file" that is used: ... (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) info source^M Current source file is ../setjmp/longjmp.c^M ... Tested on x86_64-linux, target boards unix/{-m64,-m32}. Reported-By: Luis Machado <luis.machado@arm.com> Reviewed-By: Tom Tromey <tom@tromey.com> PR testsuite/30103 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30103
2023-02-10 15:58:00 +01:00
gdb_test "break $::subdir/$::srcfile:$bp_start_test_2" \
"Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_2.*" \
"breakpoint at pattern start"
gdb_test "continue" "patt2.*" "continue to breakpoint at pattern start"
# set safe-net break
[gdb/testsuite] Fix linespec ambiguity in gdb.base/longjmp.exp PR testsuite/30103 reports the following failure on aarch64-linux (ubuntu 22.04): ... (gdb) PASS: gdb.base/longjmp.exp: with_probes=0: pattern 1: next to longjmp next warning: Breakpoint address adjusted from 0x83dc305fef755015 to \ 0xffdc305fef755015. Warning: Cannot insert breakpoint 0. Cannot access memory at address 0xffdc305fef755015 __libc_siglongjmp (env=0xaaaaaaab1018 <env>, val=1) at ./setjmp/longjmp.c:30 30 } (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) delete breakpoints Delete all breakpoints? (y or n) y (gdb) info breakpoints No breakpoints or watchpoints. (gdb) break 63 No line 63 in the current file. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint \ at pattern start (got interactive prompt) ... The test-case intends to set the breakpoint on line number 63 in gdb.base/longjmp.c. It tries to do so by specifying "break 63", which specifies a line in the "current source file". Due to the KFAIL PR, gdb stopped in __libc_siglongjmp, and because of presence of debug info, the "current source file" becomes glibc's ./setjmp/longjmp.c. Consequently, setting the breakpoint fails. Fix this by adding a $subdir/$srcfile: prefix to the breakpoint linespecs. I've managed to reproduce the FAIL on x86_64/-m32, by installing the glibc-32bit-debuginfo package. This allowed me to confirm the "current source file" that is used: ... (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) info source^M Current source file is ../setjmp/longjmp.c^M ... Tested on x86_64-linux, target boards unix/{-m64,-m32}. Reported-By: Luis Machado <luis.machado@arm.com> Reviewed-By: Tom Tromey <tom@tromey.com> PR testsuite/30103 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30103
2023-02-10 15:58:00 +01:00
gdb_test "break $::subdir/$::srcfile:$bp_miss_step_2" \
"Breakpoint.*at.* file .*$::srcfile, line.*$bp_miss_step_2.*" \
"breakpoint at safety net"
}
gdb_test "next" "call_longjmp.*" "next over setjmp"
set msg "next over call_longjmp"
gdb_test_multiple "next" $msg {
-re ".*patt2.*$::gdb_prompt $" {
pass $msg
gdb_test "next" "resumes\\+\\+.*" "next into else block"
gdb_test "next" "miss_step_2.*" "next into safety net"
}
-re "miss_step_2.*$::gdb_prompt $" {
if { $have_longjmp_probe } {
fail $gdb_test_name
} else {
kfail $gdb_test_name "gdb/26967"
}
}
-re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
if { $have_longjmp_probe } {
fail $gdb_test_name
} else {
kfail $gdb_test_name "gdb/26967"
}
}
}
}
#
# Pattern 3 - setjmp/longjmp inside stepped-over function.
#
with_test_prefix "pattern 3" {
with_test_prefix setup {
delete_breakpoints
[gdb/testsuite] Fix linespec ambiguity in gdb.base/longjmp.exp PR testsuite/30103 reports the following failure on aarch64-linux (ubuntu 22.04): ... (gdb) PASS: gdb.base/longjmp.exp: with_probes=0: pattern 1: next to longjmp next warning: Breakpoint address adjusted from 0x83dc305fef755015 to \ 0xffdc305fef755015. Warning: Cannot insert breakpoint 0. Cannot access memory at address 0xffdc305fef755015 __libc_siglongjmp (env=0xaaaaaaab1018 <env>, val=1) at ./setjmp/longjmp.c:30 30 } (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) delete breakpoints Delete all breakpoints? (y or n) y (gdb) info breakpoints No breakpoints or watchpoints. (gdb) break 63 No line 63 in the current file. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint \ at pattern start (got interactive prompt) ... The test-case intends to set the breakpoint on line number 63 in gdb.base/longjmp.c. It tries to do so by specifying "break 63", which specifies a line in the "current source file". Due to the KFAIL PR, gdb stopped in __libc_siglongjmp, and because of presence of debug info, the "current source file" becomes glibc's ./setjmp/longjmp.c. Consequently, setting the breakpoint fails. Fix this by adding a $subdir/$srcfile: prefix to the breakpoint linespecs. I've managed to reproduce the FAIL on x86_64/-m32, by installing the glibc-32bit-debuginfo package. This allowed me to confirm the "current source file" that is used: ... (gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \ (PRMS: next over longjmp) info source^M Current source file is ../setjmp/longjmp.c^M ... Tested on x86_64-linux, target boards unix/{-m64,-m32}. Reported-By: Luis Machado <luis.machado@arm.com> Reviewed-By: Tom Tromey <tom@tromey.com> PR testsuite/30103 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30103
2023-02-10 15:58:00 +01:00
gdb_test "break $::subdir/$::srcfile:$bp_start_test_3" \
"Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_3.*" \
"breakpoint at pattern start"
gdb_test "continue" "patt3.*" "continue to breakpoint at pattern start"
}
gdb_test_multiple "next" "next over pattern" {
-re -wrap "longjmp caught.*" {
pass $gdb_test_name
}
-re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
if { $have_longjmp_probe } {
fail $gdb_test_name
} else {
kfail $gdb_test_name "gdb/26967"
}
}
}
}
}
foreach_with_prefix with_probes { 0 1 } {
do_test $with_probes
}