From: Andrew Burgess <aburgess@redhat.com>
To: Abhay Kandpal <abhay@linux.ibm.com>,
Tom de Vries <tdevries@suse.de>, Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior
Date: Tue, 08 Sep 2026 17:27:19 +0100 [thread overview]
Message-ID: <874ifzr9nc.fsf@redhat.com> (raw)
In-Reply-To: <c9b063c8-0c03-4529-8233-249218fc0662@linux.ibm.com>
Abhay Kandpal <abhay@linux.ibm.com> writes:
> Hi Tom,
>
> I see two more from the same commit on powerpc64le-linux:
>
> FAIL: gdb.compile/compile.exp: expect no 5
> FAIL: gdb.compile/compile-cplus.exp: expect 5
>
> Bisected to 32090b27e92 as well. I sent the details to the
> mailing list yesterday and have also added them to PR 34602.
Hi,
I've run out of time to continue looking at this today, so I wanted to
share what I have currently. I can reproduce the gdb.compile/ failures,
and the patch below fixes them. I have not yet reproduced the gdb.ada/
failures, but there are only a couple of malloc related calls from these
tests, so I think this is likely a similar issue to the gdb.compile/,
just from a different place in GDB.
The patch below does (for me) fix gdb.copile/, and I suspect will fix
gdb.ada/ too, though this is just a guess.
I need to finish writing up the commit message (like I said: ENOTIME),
but I'll finish this off tomorrow and post this as a new thread.
Before then, if you wanted to test this patch, especially Tom de Vries
for the gdb.ada/ regressions, do let me know how you get on.
thanks,
Andrew
--
commit 7e023bcaf91d062ade1f0e34b3292d8a3e6be9a1
Author: Andrew Burgess <aburgess@redhat.com>
Date: Tue Sep 8 12:06:26 2026 -0400
[wip] gdb: fill in default return types for some inferior function calls
After commit:
commit 32090b27e92cb8fd4998e8e8e65d43f445545bc7
Date: Wed Sep 2 10:43:34 2026 +0100
gdb: fix incorrect search domain in find_function_in_inferior
Some regressions were reported against the tests:
gdb.ada/funcall_ref.exp
gdb.ada/arrayparam.exp
gdb.compile/compile.exp
gdb.compile/compile-cplus.exp
I've not been able to reproduce the gdb.ada/* regressions, but I could
reproduce the gdb.compile/* failures. In that case what's happening
is that we are now finding a full symbol rather than a minimal symbol.
However, the full symbol lacks full type information.
When we previously took the minimal symbol path through
find_function_in_inferior we would create a fake function type for the
minimal symbol `char (*) (void)` and use this for calling the minimal
symbol.
However, the inferior function calls that are causing problems in the
gdb.compile/ case are all passing through linux_infcall_munmap in
linux-tdep.c. From linux_infcall_munmap we call
find_function_in_inferior and then call_function_by_hand.
When we call call_function_by_hand we pass NULL as the second
argument, the second argument being the default return type. This
means that because the full symbol we found lacks a return type
call_function_by_hand will throw an error.
If instead I updated linux_infcall_munmap to pass a suitable default
return type into call_function_by_hand, then GDB can now make the
inferior function call, and the gdb.compile/* errors are resolved.
TODO: Explain the change the might fix the gdb.ada/* regressions.
TODO: Explain the other changes.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34602
diff --git a/gdb/gcore.c b/gdb/gcore.c
index e50115370c7..77d915505d1 100644
--- a/gdb/gcore.c
+++ b/gdb/gcore.c
@@ -292,7 +292,9 @@ call_target_sbrk (int sbrk_arg)
target_sbrk_arg = value_from_longest (builtin_type (gdbarch)->builtin_int,
sbrk_arg);
gdb_assert (target_sbrk_arg);
- ret = call_function_by_hand (sbrk_fn, NULL, target_sbrk_arg);
+ ret = call_function_by_hand (sbrk_fn,
+ builtin_type (gdbarch)->builtin_data_ptr,
+ target_sbrk_arg);
if (ret == NULL)
return (bfd_vma) 0;
diff --git a/gdb/linux-fork.c b/gdb/linux-fork.c
index a0ff625a41a..e11b29349fc 100644
--- a/gdb/linux-fork.c
+++ b/gdb/linux-fork.c
@@ -664,7 +664,12 @@ inferior_call_waitpid (ptid_t pptid, int pid)
argv[1] = value_from_pointer (builtin_type (gdbarch)->builtin_data_ptr, 0);
argv[2] = value_from_longest (builtin_type (gdbarch)->builtin_int, 0);
- retv = call_function_by_hand (waitpid_fn, NULL, argv);
+ /* Use `int` default return type, even though waitpid actually
+ returns pid_t. This matches ARGV[0] above, which is
+ similarly of type pid_t, but we treat as `int`. */
+ retv = call_function_by_hand (waitpid_fn,
+ builtin_type (gdbarch)->builtin_int,
+ argv);
if (value_as_long (retv) >= 0)
ret = 0;
@@ -1007,7 +1012,11 @@ checkpoint_command (const char *args, int from_tty)
scoped_restore save_pid
= make_scoped_restore (&checkpointing_pid, inferior_ptid.pid ());
- ret = call_function_by_hand (fork_fn, NULL, {});
+ /* Use `int` as the default return type even though fork actually
+ returns pid_t. */
+ ret = call_function_by_hand (fork_fn,
+ builtin_type (gdbarch)->builtin_int,
+ {});
}
if (!ret) /* Probably can't happen. */
diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
index e37c400bed1..05ee71fc96f 100644
--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -2946,7 +2946,9 @@ linux_infcall_mmap (CORE_ADDR size, unsigned prot)
arg[ARG_FD] = value_from_longest (builtin_type (gdbarch)->builtin_int, -1);
arg[ARG_OFFSET] = value_from_longest (builtin_type (gdbarch)->builtin_int64,
0);
- addr_val = call_function_by_hand (mmap_val, NULL, arg);
+ addr_val = call_function_by_hand (mmap_val,
+ builtin_type (gdbarch)->builtin_data_ptr,
+ arg);
retval = value_as_address (addr_val);
if (retval == (CORE_ADDR) -1)
error (_("Failed inferior mmap call for %s bytes, errno is changed."),
@@ -2975,7 +2977,9 @@ linux_infcall_munmap (CORE_ADDR addr, CORE_ADDR size)
/* Assuming sizeof (unsigned long) == sizeof (size_t). */
arg[ARG_LENGTH] = value_from_ulongest
(builtin_type (gdbarch)->builtin_unsigned_long, size);
- retval_val = call_function_by_hand (munmap_val, NULL, arg);
+ retval_val = call_function_by_hand (munmap_val,
+ builtin_type (gdbarch)->builtin_int,
+ arg);
retval = value_as_long (retval_val);
if (retval != 0)
warning (_("Failed inferior munmap call at %s for %s bytes, "
diff --git a/gdb/valops.c b/gdb/valops.c
index e214342c40d..2ff15de7c68 100644
--- a/gdb/valops.c
+++ b/gdb/valops.c
@@ -176,7 +176,9 @@ value_allocate_space_in_inferior (int len)
struct value *blocklen;
blocklen = value_from_longest (builtin_type (gdbarch)->builtin_int, len);
- val = call_function_by_hand (val, NULL, blocklen);
+ val = call_function_by_hand (val,
+ builtin_type (gdbarch)->builtin_data_ptr,
+ blocklen);
if (value_logical_not (val))
{
if (!target_has_execution ())
next prev parent reply other threads:[~2026-09-08 16:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 16:16 Andrew Burgess
2026-09-03 20:23 ` Tom Tromey
2026-09-04 9:54 ` Andrew Burgess
2026-09-07 22:30 ` Tom de Vries
2026-09-08 5:52 ` Tom de Vries
2026-09-08 15:28 ` Andrew Burgess
2026-09-08 5:55 ` Abhay Kandpal
2026-09-08 16:27 ` Andrew Burgess [this message]
2026-09-08 17:23 ` Tom de Vries
2026-09-07 18:39 ` Abhay Kandpal
2026-09-08 8:05 ` Andrew Burgess
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=874ifzr9nc.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=abhay@linux.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
--cc=tom@tromey.com \
/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