Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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 ())


  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