[PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Andrew Burgess]

The find_function_in_inferior function is used when GDB needs to make
an inferior function call as part of expression evaluation, for
example, calling malloc to allocate space in the inferior, or calling
an object's constructor.

The function lookup has two phases, first we search for full symbols.
If that search fails then we fallback to looking for a minimal symbol.

The problem I see here is that the full symbol search uses
SEARCH_TYPE_DOMAIN, and has done since commit:

  commit ccf41c248737eb6650211481366c4e1156ce01ae
  Date:   Thu Mar 30 23:00:26 2023 -0600

      Use domain_search_flags in lookup_symbol et al

Prior to this commit the search was done using VAR_DOMAIN, which would
find types, variables, and functions, there was even code in place to
raise an error if the symbol we found was not a function.

The ccf41c248737eb66 commit switched to SEARCH_TYPE_DOMAIN and removed
the "is a function" check.  I think this was a mistake.  Given that
find_function_in_inferior is always used to look for a function, I
think we should have switched to SEARCH_FUNCTION_DOMAIN.  The "is a
function" check can be removed as the search will now only find
functions.

So the first thing I fixed in this commit is to change
SEARCH_TYPE_DOMAIN to SEARCH_FUNCTION_DOMAIN in
find_function_in_inferior.

With that done the next problem we encounter is that if the full
symbol is for a GNU IFUNC then we need to handle this via the minimal
symbol path.  For inspiration here I looked at the 'variable:
name_not_typename' rule in the c-exp.y file, where we say:

      /* If we found a function, see if it's
	 an ifunc resolver that has the same
	 address as the ifunc symbol itself.
	 If so, prefer the ifunc symbol.  */

I think find_function_in_inferior should apply the same logic.  To
achieve this I added a call to find_gnu_ifunc and restructured the
code slightly so that after the full symbol lookup the minimal symbol
can come from either calling lookup_minimal_symbol, or from the
find_gnu_ifunc path.

There are no new tests, but I have been using gdb.base/gnu-ifunc.exp
as a smoke test for this change.  When I have glibc debug information
installed I can (by attaching GDB to GDB) see the full symbol lookup
path now triggering, so I know that the updated code path is now being
used.

It was while reviewing commits:

  commit ca0908d623605250e6d84afb90d742c328e6bb90
  Date:   Tue Aug 11 13:12:19 2026 +0000

      gdb: Keep original IFUNC return type when target type is unknown

  commit de930032d883219559d1dba575f2c0f5359e80fc
  Date:   Tue Aug 11 13:12:18 2026 +0000

      gdb: Preserve IFUNC marker when finding inferior functions

which touched gdb.base/gnu-ifunc.exp that I spotted this bug.
---
 gdb/valops.c | 79 ++++++++++++++++++++++++++--------------------------
 1 file changed, 40 insertions(+), 39 deletions(-)

diff --git a/gdb/valops.c b/gdb/valops.c
index 82c796bd254..e214342c40d 100644
--- a/gdb/valops.c
+++ b/gdb/valops.c
@@ -113,52 +113,53 @@ struct value *
 find_function_in_inferior (const char *name, struct objfile **objf_p)
 {
   struct block_symbol sym;
+  bound_minimal_symbol msymbol;
 
-  sym = lookup_symbol (name, nullptr, SEARCH_TYPE_DOMAIN, nullptr);
-  if (sym.symbol != NULL)
+  sym = lookup_symbol (name, nullptr, SEARCH_FUNCTION_DOMAIN, nullptr);
+  if (sym.symbol != nullptr)
     {
-      if (objf_p)
-	*objf_p = sym.symbol->objfile ();
+      msymbol = find_gnu_ifunc (sym.symbol);
+      if (msymbol.minsym == nullptr)
+	{
+	  if (objf_p != nullptr)
+	    *objf_p = sym.symbol->objfile ();
+	  return value_of_variable (sym.symbol, sym.block);
+	}
+    }
+  else
+    msymbol = lookup_minimal_symbol (current_program_space, name);
 
-      return value_of_variable (sym.symbol, sym.block);
+  if (msymbol.minsym != nullptr)
+    {
+      struct objfile *objfile = msymbol.objfile;
+      struct gdbarch *gdbarch = objfile->arch ();
+
+      struct type *type;
+      CORE_ADDR maddr;
+      type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char);
+      type = lookup_function_type (type);
+      type = lookup_pointer_type (type);
+      maddr = msymbol.value_address ();
+      minimal_symbol_type minsym_type = msymbol.minsym->type ();
+
+      if (minsym_type == mst_text_gnu_ifunc
+	  || minsym_type == mst_data_gnu_ifunc)
+	type->target_type ()->set_is_gnu_ifunc (true);
+
+      if (objf_p != nullptr)
+	*objf_p = objfile;
+
+      return value_from_pointer (type, maddr);
     }
   else
     {
-      bound_minimal_symbol msymbol
-	= lookup_minimal_symbol (current_program_space, name);
-
-      if (msymbol.minsym != NULL)
-	{
-	  struct objfile *objfile = msymbol.objfile;
-	  struct gdbarch *gdbarch = objfile->arch ();
-
-	  struct type *type;
-	  CORE_ADDR maddr;
-	  type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char);
-	  type = lookup_function_type (type);
-	  type = lookup_pointer_type (type);
-	  maddr = msymbol.value_address ();
-	  minimal_symbol_type minsym_type = msymbol.minsym->type ();
-
-	  if (minsym_type == mst_text_gnu_ifunc
-	      || minsym_type == mst_data_gnu_ifunc)
-	    type->target_type ()->set_is_gnu_ifunc (true);
-
-	  if (objf_p)
-	    *objf_p = objfile;
-
-	  return value_from_pointer (type, maddr);
-	}
+      if (!target_has_execution ())
+	error (_("evaluation of this expression "
+		 "requires the target program to be active"));
       else
-	{
-	  if (!target_has_execution ())
-	    error (_("evaluation of this expression "
-		     "requires the target program to be active"));
-	  else
-	    error (_("evaluation of this expression requires the "
-		     "program to have a function \"%s\"."),
-		   name);
-	}
+	error (_("evaluation of this expression requires the "
+		 "program to have a function \"%s\"."),
+	       name);
     }
 }
 

base-commit: 9c1937eb7103bee8c329b9c4f5137fcd1726b23d
-- 
2.25.4

Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Tom Tromey]

>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:

Andrew> The problem I see here is that the full symbol search uses
Andrew> SEARCH_TYPE_DOMAIN, and has done since commit:
Andrew>   commit ccf41c248737eb6650211481366c4e1156ce01ae
Andrew>   Date:   Thu Mar 30 23:00:26 2023 -0600
Andrew>       Use domain_search_flags in lookup_symbol et al

Sorry about that.  I guess it worked by falling back to minsyms?

I think this is ok.  Thank you.
Approved-By: Tom Tromey <tom@tromey.com>

Tom

Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Andrew Burgess]

Tom Tromey <tom@tromey.com> writes:

>>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
>
> Andrew> The problem I see here is that the full symbol search uses
> Andrew> SEARCH_TYPE_DOMAIN, and has done since commit:
> Andrew>   commit ccf41c248737eb6650211481366c4e1156ce01ae
> Andrew>   Date:   Thu Mar 30 23:00:26 2023 -0600
> Andrew>       Use domain_search_flags in lookup_symbol et al
>
> Sorry about that.  I guess it worked by falling back to minsyms?

Exactly.

>
> I think this is ok.  Thank you.
> Approved-By: Tom Tromey <tom@tromey.com>

Pushed.

Thanks,
Andrew

Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Abhay Kandpal]

[-- Attachment #1: Type: text/plain, Size: 7882 bytes --]

Hi Andrew,

I think this commit causes two regressions on powerpc64le-linux,
still present on current master (e0d8f6fc386):

FAIL: gdb.compile/compile.exp: expect no 5
FAIL: gdb.compile/compile-cplus.exp: expect 5

I bisected these to 32090b27e92cb8fd4998e8e8e65d43f445545bc7.  They
reproduce on two machines here, one Fedora 43 and one Fedora 44.

Both tests check that the memory used by an injected module is released
after the compile command finishes.  After this commit it is not.

Before the commit, with "set debug compile on":

allocated 0x5f0 bytes at 0x7ffff7f30000 prot 5
allocated 0x10 bytes at 0x7ffff7db0000 prot 3
allocated 0x34 bytes at 0x7ffff7da0000 prot 1
allocated 0x8 bytes at 0x7ffff7d90000 for registers

and none of those addresses appear in "info proc mappings" once the
command has finished.  After this commit they are still mapped,
for example:
(gdb) p intptr
$1 = (int *) 0x7ffff7db0000

0x00007ffff7db0000 0x00007ffff7dc0000 0x10000  0x0  rw-p

so "p *intptr" still reads 5 from the module's memory, which is what the
tests check against.

That memory is released by munmap_list::~munmap_list in
compile/compile-object-load.c, which calls gdbarch_infcall_munmap.  On

Linux that is linux_infcall_munmap (linux-tdep.c:2960), which looks up
"munmap" with find_function_in_inferior.  The destructor discards any
exception, so a failure there would be silent.

The allocations themselves still work, and linux_infcall_mmap looks up
"mmap64" through the same function, so whatever changed seems to affect
the lookup of "munmap" but not "mmap64".

Since GDB 18.1 is due on the 11th, I thought it was worth flagging now.

Thanks,
Abhay

On 02/09/26 21:46, Andrew Burgess wrote:
> The find_function_in_inferior function is used when GDB needs to make
> an inferior function call as part of expression evaluation, for
> example, calling malloc to allocate space in the inferior, or calling
> an object's constructor.
>
> The function lookup has two phases, first we search for full symbols.
> If that search fails then we fallback to looking for a minimal symbol.
>
> The problem I see here is that the full symbol search uses
> SEARCH_TYPE_DOMAIN, and has done since commit:
>
>    commit ccf41c248737eb6650211481366c4e1156ce01ae
>    Date:   Thu Mar 30 23:00:26 2023 -0600
>
>        Use domain_search_flags in lookup_symbol et al
>
> Prior to this commit the search was done using VAR_DOMAIN, which would
> find types, variables, and functions, there was even code in place to
> raise an error if the symbol we found was not a function.
>
> The ccf41c248737eb66 commit switched to SEARCH_TYPE_DOMAIN and removed
> the "is a function" check.  I think this was a mistake.  Given that
> find_function_in_inferior is always used to look for a function, I
> think we should have switched to SEARCH_FUNCTION_DOMAIN.  The "is a
> function" check can be removed as the search will now only find
> functions.
>
> So the first thing I fixed in this commit is to change
> SEARCH_TYPE_DOMAIN to SEARCH_FUNCTION_DOMAIN in
> find_function_in_inferior.
>
> With that done the next problem we encounter is that if the full
> symbol is for a GNU IFUNC then we need to handle this via the minimal
> symbol path.  For inspiration here I looked at the 'variable:
> name_not_typename' rule in the c-exp.y file, where we say:
>
>        /* If we found a function, see if it's
> 	 an ifunc resolver that has the same
> 	 address as the ifunc symbol itself.
> 	 If so, prefer the ifunc symbol.  */
>
> I think find_function_in_inferior should apply the same logic.  To
> achieve this I added a call to find_gnu_ifunc and restructured the
> code slightly so that after the full symbol lookup the minimal symbol
> can come from either calling lookup_minimal_symbol, or from the
> find_gnu_ifunc path.
>
> There are no new tests, but I have been using gdb.base/gnu-ifunc.exp
> as a smoke test for this change.  When I have glibc debug information
> installed I can (by attaching GDB to GDB) see the full symbol lookup
> path now triggering, so I know that the updated code path is now being
> used.
>
> It was while reviewing commits:
>
>    commit ca0908d623605250e6d84afb90d742c328e6bb90
>    Date:   Tue Aug 11 13:12:19 2026 +0000
>
>        gdb: Keep original IFUNC return type when target type is unknown
>
>    commit de930032d883219559d1dba575f2c0f5359e80fc
>    Date:   Tue Aug 11 13:12:18 2026 +0000
>
>        gdb: Preserve IFUNC marker when finding inferior functions
>
> which touched gdb.base/gnu-ifunc.exp that I spotted this bug.
> ---
>   gdb/valops.c | 79 ++++++++++++++++++++++++++--------------------------
>   1 file changed, 40 insertions(+), 39 deletions(-)
>
> diff --git a/gdb/valops.c b/gdb/valops.c
> index 82c796bd254..e214342c40d 100644
> --- a/gdb/valops.c
> +++ b/gdb/valops.c
> @@ -113,52 +113,53 @@ struct value *
>   find_function_in_inferior (const char *name, struct objfile **objf_p)
>   {
>     struct block_symbol sym;
> +  bound_minimal_symbol msymbol;
>   
> -  sym = lookup_symbol (name, nullptr, SEARCH_TYPE_DOMAIN, nullptr);
> -  if (sym.symbol != NULL)
> +  sym = lookup_symbol (name, nullptr, SEARCH_FUNCTION_DOMAIN, nullptr);
> +  if (sym.symbol != nullptr)
>       {
> -      if (objf_p)
> -	*objf_p = sym.symbol->objfile ();
> +      msymbol = find_gnu_ifunc (sym.symbol);
> +      if (msymbol.minsym == nullptr)
> +	{
> +	  if (objf_p != nullptr)
> +	    *objf_p = sym.symbol->objfile ();
> +	  return value_of_variable (sym.symbol, sym.block);
> +	}
> +    }
> +  else
> +    msymbol = lookup_minimal_symbol (current_program_space, name);
>   
> -      return value_of_variable (sym.symbol, sym.block);
> +  if (msymbol.minsym != nullptr)
> +    {
> +      struct objfile *objfile = msymbol.objfile;
> +      struct gdbarch *gdbarch = objfile->arch ();
> +
> +      struct type *type;
> +      CORE_ADDR maddr;
> +      type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char);
> +      type = lookup_function_type (type);
> +      type = lookup_pointer_type (type);
> +      maddr = msymbol.value_address ();
> +      minimal_symbol_type minsym_type = msymbol.minsym->type ();
> +
> +      if (minsym_type == mst_text_gnu_ifunc
> +	  || minsym_type == mst_data_gnu_ifunc)
> +	type->target_type ()->set_is_gnu_ifunc (true);
> +
> +      if (objf_p != nullptr)
> +	*objf_p = objfile;
> +
> +      return value_from_pointer (type, maddr);
>       }
>     else
>       {
> -      bound_minimal_symbol msymbol
> -	= lookup_minimal_symbol (current_program_space, name);
> -
> -      if (msymbol.minsym != NULL)
> -	{
> -	  struct objfile *objfile = msymbol.objfile;
> -	  struct gdbarch *gdbarch = objfile->arch ();
> -
> -	  struct type *type;
> -	  CORE_ADDR maddr;
> -	  type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char);
> -	  type = lookup_function_type (type);
> -	  type = lookup_pointer_type (type);
> -	  maddr = msymbol.value_address ();
> -	  minimal_symbol_type minsym_type = msymbol.minsym->type ();
> -
> -	  if (minsym_type == mst_text_gnu_ifunc
> -	      || minsym_type == mst_data_gnu_ifunc)
> -	    type->target_type ()->set_is_gnu_ifunc (true);
> -
> -	  if (objf_p)
> -	    *objf_p = objfile;
> -
> -	  return value_from_pointer (type, maddr);
> -	}
> +      if (!target_has_execution ())
> +	error (_("evaluation of this expression "
> +		 "requires the target program to be active"));
>         else
> -	{
> -	  if (!target_has_execution ())
> -	    error (_("evaluation of this expression "
> -		     "requires the target program to be active"));
> -	  else
> -	    error (_("evaluation of this expression requires the "
> -		     "program to have a function \"%s\"."),
> -		   name);
> -	}
> +	error (_("evaluation of this expression requires the "
> +		 "program to have a function \"%s\"."),
> +	       name);
>       }
>   }
>   
>
> base-commit: 9c1937eb7103bee8c329b9c4f5137fcd1726b23d

[-- Attachment #2: Type: text/html, Size: 9243 bytes --]

Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Tom de Vries]

On 9/4/26 11:54 AM, Andrew Burgess wrote:
> Tom Tromey <tom@tromey.com> writes:
> 
>>>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
>>
>> Andrew> The problem I see here is that the full symbol search uses
>> Andrew> SEARCH_TYPE_DOMAIN, and has done since commit:
>> Andrew>   commit ccf41c248737eb6650211481366c4e1156ce01ae
>> Andrew>   Date:   Thu Mar 30 23:00:26 2023 -0600
>> Andrew>       Use domain_search_flags in lookup_symbol et al
>>
>> Sorry about that.  I guess it worked by falling back to minsyms?
> 
> Exactly.
> 
>>
>> I think this is ok.  Thank you.
>> Approved-By: Tom Tromey <tom@tromey.com>
> 
> Pushed.

Hi,

I see (at least two) regressions that bisect to this patch.

I've reported this here ( 
https://sourceware.org/bugzilla/show_bug.cgi?id=34602 ).

I'll do a full test run to see if I find anything else.

Thanks,
- Tom

Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Tom de Vries]

On 9/8/26 12:30 AM, Tom de Vries wrote:
> I see (at least two) regressions that bisect to this patch.
> 
> I've reported this here ( https://sourceware.org/bugzilla/show_bug.cgi? 
> id=34602 ).
> 
> I'll do a full test run to see if I find anything else.

Nothing else came up, so in summary it's just:
...
FAIL: gdb.ada/arrayparam.exp: scenario=all: print call_me("bonjour")
FAIL: gdb.ada/arrayparam.exp: scenario=all: print first after function call
FAIL: gdb.ada/arrayparam.exp: scenario=all: print last after function call
FAIL: gdb.ada/arrayparam.exp: scenario=all: print length after function call
FAIL: gdb.ada/arrayparam.exp: scenario=minimal: print call_me("bonjour")
FAIL: gdb.ada/arrayparam.exp: scenario=minimal: print first after 
function call
FAIL: gdb.ada/arrayparam.exp: scenario=minimal: print last after 
function call
FAIL: gdb.ada/arrayparam.exp: scenario=minimal: print length after 
function call
FAIL: gdb.ada/funcall_ref.exp: scenario=all: p get("Hello world!")
...

Thanks,
- Tom

Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Abhay Kandpal]

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

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.

Thanks,
Abhay



On 08/09/26 04:00, Tom de Vries wrote:
> On 9/4/26 11:54 AM, Andrew Burgess wrote:
>> Tom Tromey <tom@tromey.com> writes:
>>
>>>>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
>>>
>>> Andrew> The problem I see here is that the full symbol search uses
>>> Andrew> SEARCH_TYPE_DOMAIN, and has done since commit:
>>> Andrew>   commit ccf41c248737eb6650211481366c4e1156ce01ae
>>> Andrew>   Date:   Thu Mar 30 23:00:26 2023 -0600
>>> Andrew>       Use domain_search_flags in lookup_symbol et al
>>>
>>> Sorry about that.  I guess it worked by falling back to minsyms?
>>
>> Exactly.
>>
>>>
>>> I think this is ok.  Thank you.
>>> Approved-By: Tom Tromey <tom@tromey.com>
>>
>> Pushed.
>
> Hi,
>
> I see (at least two) regressions that bisect to this patch.
>
> I've reported this here ( 
> https://sourceware.org/bugzilla/show_bug.cgi?id=34602 ).
>
> I'll do a full test run to see if I find anything else.
>
> Thanks,
> - Tom
>

[-- Attachment #2: Type: text/html, Size: 3391 bytes --]

Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Andrew Burgess]

Abhay Kandpal <abhay@linux.ibm.com> writes:

> Hi Andrew,
>
> I think this commit causes two regressions on powerpc64le-linux,
> still present on current master (e0d8f6fc386):
>
> FAIL: gdb.compile/compile.exp: expect no 5
> FAIL: gdb.compile/compile-cplus.exp: expect 5
>
> I bisected these to 32090b27e92cb8fd4998e8e8e65d43f445545bc7.  They
> reproduce on two machines here, one Fedora 43 and one Fedora 44.
>
> Both tests check that the memory used by an injected module is released
> after the compile command finishes.  After this commit it is not.
>
> Before the commit, with "set debug compile on":
>
> allocated 0x5f0 bytes at 0x7ffff7f30000 prot 5
> allocated 0x10 bytes at 0x7ffff7db0000 prot 3
> allocated 0x34 bytes at 0x7ffff7da0000 prot 1
> allocated 0x8 bytes at 0x7ffff7d90000 for registers
>
> and none of those addresses appear in "info proc mappings" once the
> command has finished.  After this commit they are still mapped,
> for example:
> (gdb) p intptr
> $1 = (int *) 0x7ffff7db0000
>
> 0x00007ffff7db0000 0x00007ffff7dc0000 0x10000  0x0  rw-p
>
> so "p *intptr" still reads 5 from the module's memory, which is what the
> tests check against.
>
> That memory is released by munmap_list::~munmap_list in
> compile/compile-object-load.c, which calls gdbarch_infcall_munmap.  On
>
> Linux that is linux_infcall_munmap (linux-tdep.c:2960), which looks up
> "munmap" with find_function_in_inferior.  The destructor discards any
> exception, so a failure there would be silent.
>
> The allocations themselves still work, and linux_infcall_mmap looks up
> "mmap64" through the same function, so whatever changed seems to affect
> the lookup of "munmap" but not "mmap64".
>
> Since GDB 18.1 is due on the 11th, I thought it was worth flagging now.

Thanks, I will investigate these, but the good news is that
32090b27e92cb8fd4998e8e8e65d43f445545bc7 is not on the gdb-18-branch.
You can confirm this with:

  $ git branch -a --contains 32090b27e92cb8fd4998e8e8e65d43f445545bc7 | grep -e "gdb-.*-branch"

which will return no hits.

But I'll still be looking into what is happening here.

Thanks,
Andrew

Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Andrew Burgess]

Tom de Vries <tdevries@suse.de> writes:

> On 9/8/26 12:30 AM, Tom de Vries wrote:
>> I see (at least two) regressions that bisect to this patch.
>> 
>> I've reported this here ( https://sourceware.org/bugzilla/show_bug.cgi? 
>> id=34602 ).
>> 
>> I'll do a full test run to see if I find anything else.
>
> Nothing else came up, so in summary it's just:
> ...
> FAIL: gdb.ada/arrayparam.exp: scenario=all: print call_me("bonjour")
> FAIL: gdb.ada/arrayparam.exp: scenario=all: print first after function call
> FAIL: gdb.ada/arrayparam.exp: scenario=all: print last after function call
> FAIL: gdb.ada/arrayparam.exp: scenario=all: print length after function call
> FAIL: gdb.ada/arrayparam.exp: scenario=minimal: print call_me("bonjour")
> FAIL: gdb.ada/arrayparam.exp: scenario=minimal: print first after 
> function call
> FAIL: gdb.ada/arrayparam.exp: scenario=minimal: print last after 
> function call
> FAIL: gdb.ada/arrayparam.exp: scenario=minimal: print length after 
> function call
> FAIL: gdb.ada/funcall_ref.exp: scenario=all: p get("Hello world!")
> ...

Thanks for reporting this.  These tests definitely pass on my local
x86-64 box, I'll try some others and see if I can reproduce the
failure.  I do have an openSUSE VM, so I'll give that a try.

Thanks,
Andrew

Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Andrew Burgess]

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

Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior

[Tom de Vries]

On 9/8/26 6:27 PM, Andrew Burgess wrote:
> 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.

Hi Andrew,

I've applied the patch, it didn't fix the regressions.

I did:
...
$ gdb -q -batch -x outputs/gdb.ada/funcall_ref/gdb.in.1
...
which reproduced the failure, and "catch throw" brought me to:
...
static const block *
ada_alias_get_block_value (const struct symbol *sym)
{
   const char *name = get_imported_name (sym);
   block_symbol real_symbol = lookup_global_symbol (name, nullptr,
                                                    SEARCH_TYPE_DOMAIN);
   if (real_symbol.symbol == nullptr)
     error (_("could not find alias '%s' for function '%ps'"),
            name,
            styled_string (function_name_style.style (), sym->print_name 
()));
...

I reverted both patches and put a breakpoint on 
ada_alias_get_block_value, but it didn't get triggered.

Thanks,
- Tom