From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH] [gdb/testsuite] Add PR gdb/26967 KFAIL in two more test-cases
Date: Tue, 19 Mar 2024 08:44:49 +0100 [thread overview]
Message-ID: <20240319074449.10361-1-tdevries@suse.de> (raw)
On aarch64-linux (debian 12), when running test-case
gdb.base/longjmp-until-in-main.exp, I run into:
...
(gdb) until 33^M
warning: Breakpoint address adjusted from 0x70f727c678928489 to 0xfff727c678928489.^M
Warning:^M
Cannot insert breakpoint 0.^M
Cannot access memory at address 0xfff727c678928489^M
^M
0x0000fffff7e3a580 in siglongjmp () from /lib/aarch64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.base/longjmp-until-in-main.exp: until $line, in main
...
This is PR gdb/26967: no longjmp probe is available:
...
(gdb) info probes stap libc ^longjmp$^M
No probes matched.^M
...
and glibc applies pointer mangling which makes it fairly difficult for gdb to
get the longjmp target.
There's a KFAIL for this in test-case gdb.base/longjmp.exp, added in commit
b5e7cd5cd3d ("[gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp").
Likewise, add a KFAIL in this and one more test-case.
Tested on aarch64-linux.
---
.../gdb.base/longjmp-until-in-main.exp | 33 +++++++++++++++++--
.../premature-dummy-frame-removal.exp | 31 ++++++++++++++++-
2 files changed, 60 insertions(+), 4 deletions(-)
diff --git a/gdb/testsuite/gdb.base/longjmp-until-in-main.exp b/gdb/testsuite/gdb.base/longjmp-until-in-main.exp
index d755c86ed88..2a28b78d412 100644
--- a/gdb/testsuite/gdb.base/longjmp-until-in-main.exp
+++ b/gdb/testsuite/gdb.base/longjmp-until-in-main.exp
@@ -35,10 +35,37 @@ if {![runto_main]} {
return
}
+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
+ }
+}
+
delete_breakpoints
set until_to_line [gdb_get_line_number "until to here"]
-gdb_test "until $until_to_line" \
- " until to here .*" \
- "until \$line, in main"
+set re_cannot_insert_bp \
+ [multi_line \
+ "Warning:" \
+ "Cannot insert breakpoint $::decimal\\." \
+ "Cannot access memory at address $::hex"]
+
+set test "until \$line, in main"
+gdb_test_multiple "until $until_to_line" $test {
+ -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
+ if { $have_longjmp_probe } {
+ fail $gdb_test_name
+ } else {
+ kfail gdb/26967 $gdb_test_name
+ }
+ }
+ -re -wrap " until to here .*" {
+ pass $gdb_test_name
+ }
+}
diff --git a/gdb/testsuite/gdb.base/premature-dummy-frame-removal.exp b/gdb/testsuite/gdb.base/premature-dummy-frame-removal.exp
index 100c24aae20..a641fd66c06 100644
--- a/gdb/testsuite/gdb.base/premature-dummy-frame-removal.exp
+++ b/gdb/testsuite/gdb.base/premature-dummy-frame-removal.exp
@@ -49,7 +49,36 @@ if {![runto_main]} {
set pyfile [gdb_remote_download host ${srcdir}/${subdir}/${testfile}.py]
gdb_test_no_output "source ${pyfile}" "load python file"
-gdb_test "p some_func ()" " = 0"
+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 re_cannot_insert_bp \
+ [multi_line \
+ "Warning:" \
+ "Cannot insert breakpoint $::decimal\\." \
+ "Cannot access memory at address $::hex"]
+
+gdb_test_multiple "p some_func ()" "" {
+ -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
+ if { $have_longjmp_probe } {
+ fail $gdb_test_name
+ } else {
+ kfail gdb/26967 $gdb_test_name
+ return 0
+ }
+ }
+ -re -wrap " = 0" {
+ pass $gdb_test_name
+ }
+}
# When frame debugging is turned on, this test has (previously)
# revealed some crashes due to the Python frame unwinder trying to
base-commit: a8354784a88cab5ddc212d9d2b9d51a4abd1d12d
--
2.35.3
next reply other threads:[~2024-03-19 7:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-19 7:44 Tom de Vries [this message]
2024-03-19 13:29 ` Tom Tromey
2024-03-20 9:15 ` Tom de Vries
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=20240319074449.10361-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).