From: tdevries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH] [gdb] Fix segfault during inferior call to ifunc
Date: Tue, 27 Dec 2022 09:54:43 +0000 [thread overview]
Message-ID: <1a76ba98dddbd6c3dad498332d56f78e@suse.de> (raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: 0001-gdb-Fix-segfault-during-inferior-call-to-ifunc.patch --]
[-- Type: text/x-patch; name=0001-gdb-Fix-segfault-during-inferior-call-to-ifunc.patch, Size: 3438 bytes --]
From 0832e20dde6ebe71a1245935f4a41308368b6094 Mon Sep 17 00:00:00 2001
From: Andrew Burgess <aburgess@redhat.com>
Date: Mon, 26 Dec 2022 09:03:19 +0100
Subject: [PATCH] [gdb] Fix segfault during inferior call to ifunc
With a simple test-case:
...
$ cat test.c
char *p = "a";
int main (void) {
return strlen (p);
}
$ gcc -g test.c
...
we run into this segfault:
...
$ gdb -q -batch a.out -ex start -ex "p strlen (p)"
Temporary breakpoint 1 at 0x1151: file test.c, line 4.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main () at test.c:4
4 return strlen (p);
Fatal signal: Segmentation fault
...
The strlen is an ifunc, and consequently during the call to
call_function_by_hand_dummy for "p strlen (p)" another call
to call_function_by_hand_dummy is used to resolve the ifunc.
This invalidates the get_current_frame () result in the outer call.
Fix this by using prepare_reinflate and reinflate.
Note that this series (
https://inbox.sourceware.org/gdb-patches/20221214033441.499512-1-simon.marchi@polymtl.ca/ )
should address this problem, but this patch is a simpler fix which is easy to
backport.
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
PR gdb/29941
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29941
---
gdb/infcall.c | 3 +++
gdb/testsuite/gdb.base/gnu-ifunc.exp | 9 +++++++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/gdb/infcall.c b/gdb/infcall.c
index c1db3e22189..ec9669a6b6a 100644
--- a/gdb/infcall.c
+++ b/gdb/infcall.c
@@ -848,6 +848,7 @@ call_function_by_hand_dummy (struct value *function,
bool stack_temporaries = thread_stack_temporaries_enabled_p (call_thread.get ());
frame = get_current_frame ();
+ frame.prepare_reinflate ();
gdbarch = get_frame_arch (frame);
if (!gdbarch_push_dummy_call_p (gdbarch))
@@ -863,6 +864,8 @@ call_function_by_hand_dummy (struct value *function,
"target calling convention."),
get_function_name (funaddr, name_buf, sizeof (name_buf)));
+ frame.reinflate ();
+
if (values_type == NULL || values_type->is_stub ())
values_type = default_return_type;
if (values_type == NULL)
diff --git a/gdb/testsuite/gdb.base/gnu-ifunc.exp b/gdb/testsuite/gdb.base/gnu-ifunc.exp
index 715f5be04cb..3b3d5cb3742 100644
--- a/gdb/testsuite/gdb.base/gnu-ifunc.exp
+++ b/gdb/testsuite/gdb.base/gnu-ifunc.exp
@@ -240,14 +240,19 @@ proc misc_tests {resolver_attr resolver_debug final_debug} {
# Test GDB will automatically indirect the call.
if {!$resolver_debug && !$final_debug} {
+ # Do the test that is supposed to succeed first, to make sure
+ # elf_gnu_ifunc_record_cache is empty. This excercises PR28224.
+ gdb_test "p (int) gnu_ifunc (3)" " = 4"
+
gdb_test "p gnu_ifunc()" \
"'${dot}final' has unknown return type; cast the call to its declared return type"
gdb_test "p gnu_ifunc (3)" \
"'${dot}final' has unknown return type; cast the call to its declared return type"
- gdb_test "p (int) gnu_ifunc (3)" " = 4"
} else {
- gdb_test "p gnu_ifunc()" "Too few arguments in function call\\."
+ # Do the test that is supposed to succeed first, see above.
gdb_test "p gnu_ifunc (3)" " = 4"
+
+ gdb_test "p gnu_ifunc()" "Too few arguments in function call\\."
}
# Test that the resolver received its argument.
--
2.34.1
next reply other threads:[~2022-12-27 9:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-27 9:54 tdevries [this message]
2023-01-02 14:41 ` Tom Tromey
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=1a76ba98dddbd6c3dad498332d56f78e@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).