From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH] [gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp
Date: Wed, 7 Dec 2022 11:35:54 +0100 [thread overview]
Message-ID: <20221207103554.23121-1-tdevries@suse.de> (raw)
Add KFAILs in test-case gdb.base/longjmp.exp for PR gdb/26967, covering
various ways that gdb is unable to recover the longjmp target if the libc
probe is not supported.
Tested on x86_64-linux.
---
gdb/testsuite/gdb.base/longjmp.exp | 82 ++++++++++++++++++++++++++++--
1 file changed, 79 insertions(+), 3 deletions(-)
diff --git a/gdb/testsuite/gdb.base/longjmp.exp b/gdb/testsuite/gdb.base/longjmp.exp
index 10e440bfca8..0f78304a14a 100644
--- a/gdb/testsuite/gdb.base/longjmp.exp
+++ b/gdb/testsuite/gdb.base/longjmp.exp
@@ -31,6 +31,43 @@ 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
+ }
+}
+
set bp_miss_step_1 [gdb_get_line_number "miss_step_1"]
set bp_miss_step_2 [gdb_get_line_number "miss_step_2"]
@@ -38,6 +75,12 @@ 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.
#
@@ -69,7 +112,18 @@ with_test_prefix "pattern 1" {
gdb_test "next" "miss_step_1.*" "next into safety net"
}
-re "miss_step_1.*$gdb_prompt $" {
- fail $msg
+ 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"
+ }
}
}
}
@@ -105,7 +159,18 @@ with_test_prefix "pattern 2" {
gdb_test "next" "miss_step_2.*" "next into safety net"
}
-re "miss_step_2.*$gdb_prompt $" {
- fail $msg
+ 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"
+ }
}
}
}
@@ -125,5 +190,16 @@ with_test_prefix "pattern 3" {
gdb_test "continue" "patt3.*" "continue to breakpoint at pattern start"
}
- gdb_test "next" "longjmp caught.*" "next over pattern"
+ 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"
+ }
+ }
+ }
}
base-commit: 3198c863f62ab2253a3405e677489b90c403cf1c
--
2.35.3
next reply other threads:[~2022-12-07 10:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-07 10:35 Tom de Vries [this message]
2022-12-07 15:22 ` Simon Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221207103554.23121-1-tdevries@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).