Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Tom de Vries <tdevries@suse.de>,
	Abhay Kandpal <abhay@linux.ibm.com>,
	Andrew Burgess <aburgess@redhat.com>
Subject: [PATCH 1/2] gdb: fill in default return types for some inferior function calls
Date: Thu, 10 Sep 2026 14:13:52 +0100	[thread overview]
Message-ID: <3b7851c296c932da6ddc366810ea6ee9f2f3db6a.1789034019.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1789034019.git.aburgess@redhat.com>

After commit:

  commit 32090b27e92cb8fd4998e8e8e65d43f445545bc7
  Date:   Wed Sep 2 10:43:34 2026 +0100

      gdb: fix incorrect search domain in find_function_in_inferior

Bug PR gdb/34602 was created which details some new regressions that
were introduced for the tests:

  gdb.ada/funcall_ref.exp
  gdb.ada/arrayparam.exp
  gdb.compile/compile.exp
  gdb.compile/compile-cplus.exp

It appears that there are two different issues here, both caused by
the changes in 32090b27e92cb8fd.  This commit addresses the issues in
the gdb.compile/ tests, the gdb.ada/ tests will be addressed in the
next commit in this series.

For the gdb.compile/ tests, what's happening is that when GDB calls
lookup_symbol, after 32090b27e92cb8fd, a full symbol is now found,
however, that symbol lacks full type information.  Crucially, the
symbol that is found lacks a return type.

Prior to commit 32090b27e92cb8fd, lookup_symbol would always fail, so
GDB would fall through to the minimal symbol lookup path.  On this
path GDB supplies some fake type information for any symbol found,
specifically, the function is claimed to return 'char'.

For the gdb.compile/ tests the problem is caused when
munmap_list::~munmap_list calls gdbarch_infcall_munmap, which on
Linux, calls linux_infcall_munmap.

In linux_infcall_munmap, find_function_in_inferior is called, which
now finds a symbol with an unknown return type, then
call_function_by_hand is called to invoke the function.

Interestingly, call_function_by_hand allows for a default return type
to be passed in, but this is not used in this case.  Instead we pass
NULL, which means that call_function_by_hand will fail if the return
type is unknown, which is what happens in this case, and this causes
the test failures.

Given that the return type for munmap is well defined, I think the fix
here is to update the call_function_by_hand call to pass in the known
default return type.  With this done the gdb.compile/ tests now start
passing again.

I could have stopped at that point, but I wondered if there were any
other places that might benefit from the same fix.  I looked for all
the call_function_by_hand calls, and updated those places where a
trivial libc function was being called, where a default return type
was reasonably straight forward.  This covered calls to: sbrk,
waitpid, fork, mmap, munmap, and malloc.

No tests here as this relies on running in an environment where there
is insufficient debug information to find the return type for munmap.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34602
---
 gdb/gcore.c      |  4 +++-
 gdb/linux-fork.c | 13 +++++++++++--
 gdb/linux-tdep.c |  8 ++++++--
 gdb/valops.c     |  4 +++-
 4 files changed, 23 insertions(+), 6 deletions(-)

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 ())
-- 
2.25.4


  reply	other threads:[~2026-09-10 13:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 13:13 [PATCH 0/2] Fix regressions after find_function_in_inferior changes Andrew Burgess
2026-09-10 13:13 ` Andrew Burgess [this message]
2026-09-11 14:38   ` [PATCH 1/2] gdb: fill in default return types for some inferior function calls Tom Tromey
2026-09-10 13:13 ` [PATCH 2/2] gdb: catch some exceptions in find_function_in_inferior Andrew Burgess
2026-09-11 11:07   ` Tom de Vries
2026-09-11 14:42     ` Tom Tromey
2026-09-11 14:43 ` [PATCH 0/2] Fix regressions after find_function_in_inferior changes 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=3b7851c296c932da6ddc366810ea6ee9f2f3db6a.1789034019.git.aburgess@redhat.com \
    --to=aburgess@redhat.com \
    --cc=abhay@linux.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tdevries@suse.de \
    /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