[PATCH 0/2] Fix regressions after find_function_in_inferior changes

[PATCH 0/2] Fix regressions after find_function_in_inferior changes

[Andrew Burgess]

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

This series fixes these regressions.  The gdb.compile/ tests are fixed
by the first patch and the gdb.ada/ tests by the second.

Thanks,
Andrew

---

Andrew Burgess (2):
  gdb: fill in default return types for some inferior function calls
  gdb: catch some exceptions in find_function_in_inferior

 gdb/gcore.c      |  4 +++-
 gdb/linux-fork.c | 13 +++++++++++--
 gdb/linux-tdep.c |  8 ++++++--
 gdb/valops.c     | 35 +++++++++++++++++++++++++----------
 4 files changed, 45 insertions(+), 15 deletions(-)


base-commit: e0d8f6fc3867435e37e0409987b63e70aee4513b
-- 
2.25.4

[PATCH 1/2] gdb: fill in default return types for some inferior function calls

[Andrew Burgess]

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

Re: [PATCH 1/2] gdb: fill in default return types for some inferior function calls

[Tom Tromey]

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

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

Makes sense to me.

Perhaps this kind of internal call should only use minsyms, with gdb
supplying the function type.

Tom

[PATCH 2/2] gdb: catch some exceptions in find_function_in_inferior

[Andrew Burgess]

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

The previous commit fixed the gdb.compile/ regressions, and this
commit fixes the gdb.ada/ regressions.

I initially struggled to reproduce this issue.  The bug was reported
against an openSUSE system, and in the end I was only able to
reproduce it on a similar openSUSE system.  I suspect this is related
to the original reporter, and myself, not having a particular debug
package installed.

The tests in question need to allocate memory in the inferior.  To do
this they call value_allocate_space_in_inferior, this calls
find_function_in_inferior, which after commit 32090b27e92cb8fd makes a
successful call to lookup_symbol.  This results in a backtrace like
this:

  #0  ada_alias_get_block_value (sym=0x213da30) at ../../src/gdb/dwarf2/ada-imported.c:107
  #1  0x0000000000db8775 in symbol::value_block (this=0x213da30) at ../../src/gdb/symtab.c:6619
  #2  0x000000000045cc1f in remove_extra_symbols (syms=std::__debug::vector of length 2, capacity 2 = {...}) at ../../src/gdb/ada-lang.c:5182
  #3  0x000000000045e236 in ada_lookup_symbol_list_worker (lookup_name=..., block=0x0, domain=..., full_search=true) at ../../src/gdb/ada-lang.c:5702
  #4  0x000000000045e3c9 in ada_lookup_symbol_list (name=0x16a3ae4 "malloc", block=0x0, domain=...) at ../../src/gdb/ada-lang.c:5727
  #5  0x000000000045e4bf in ada_lookup_symbol (name=0x16a3ae4 "malloc", block0=0x0, domain=...) at ../../src/gdb/ada-lang.c:5758
  #6  0x000000000047b15a in ada_language::lookup_symbol_nonlocal (this=0x1bfd2c0 <ada_language_defn>, name=0x16a3ae4 "malloc", block=0x0, domain=...) at ../../src/gdb/ada-lang.c:13839
  #7  0x0000000000dac991 in lookup_symbol_aux (name=0x16a3ae4 "malloc", match_type=symbol_name_match_type::FULL, block=0x0, domain=..., language=language_ada, is_a_field_of_this=0x0) at ../../src/gdb/symtab.c:2150
  #8  0x0000000000dabfab in lookup_symbol_in_language (name=0x16a3ae4 "malloc", block=0x0, domain=..., lang=language_ada, is_a_field_of_this=0x0) at ../../src/gdb/symtab.c:1961
  #9  0x0000000000dac042 in lookup_symbol (name=0x16a3ae4 "malloc", block=0x0, domain=..., is_a_field_of_this=0x0) at ../../src/gdb/symtab.c:1974
  #10 0x0000000000f36346 in find_function_in_inferior (name=0x16a3ae4 "malloc", objf_p=0x7fffffffbef8) at ../../src/gdb/valops.c:122
  #11 0x0000000000f36542 in value_allocate_space_in_inferior (len=8) at ../../src/gdb/valops.c:186

If GDB is unable to find the Ada alias for the function to be called
then an exception is thrown.  This exception propagates all the way
out of value_allocate_space_in_inferior, causing the allocation to
fail, and as a consequence, the test to fail.

My thinking here is that, if the lookup_symbol call throws an
exception then we should catch this in find_function_in_inferior and
ignore it.  The find_function_in_inferior has a minimal symbol
fallback path, so if the full symbol lookup throws an exception that
doesn't mean we cannot try the minimal symbol path.

That's what I have implemented here.  With this done the gdb.ada/
tests are now passing on my openSUSE test machine.

No new tests here as the original failure relies on being in an
environment where there is insufficient debug information to find the
Ada malloc function alias.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34602
---
 gdb/valops.c | 31 ++++++++++++++++++++++---------
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/gdb/valops.c b/gdb/valops.c
index 2ff15de7c68..a235a0ebe8d 100644
--- a/gdb/valops.c
+++ b/gdb/valops.c
@@ -112,21 +112,34 @@ show_overload_resolution (struct ui_file *file, int from_tty,
 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_FUNCTION_DOMAIN, nullptr);
-  if (sym.symbol != nullptr)
+  try
     {
-      msymbol = find_gnu_ifunc (sym.symbol);
-      if (msymbol.minsym == nullptr)
+      block_symbol sym = lookup_symbol (name, nullptr, SEARCH_FUNCTION_DOMAIN,
+					nullptr);
+
+      if (sym.symbol != nullptr)
 	{
-	  if (objf_p != nullptr)
-	    *objf_p = sym.symbol->objfile ();
-	  return value_of_variable (sym.symbol, sym.block);
+	  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
+  catch (const gdb_exception_error &)
+    {
+      /* Ignore the error.  If there's a problem looking for the full
+	 symbol then we shouldn't give up, we should fall back to
+	 looking for the minimal symbol.  */
+    }
+
+  /* If we didn't find an IFunc related minimal symbol above, then
+     look for a suitable minimal symbol now.  */
+  if (msymbol.minsym == nullptr)
     msymbol = lookup_minimal_symbol (current_program_space, name);
 
   if (msymbol.minsym != nullptr)
-- 
2.25.4

Re: [PATCH 2/2] gdb: catch some exceptions in find_function_in_inferior

[Tom de Vries]

On 9/10/26 3:13 PM, Andrew Burgess wrote:
> 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
> 
> The previous commit fixed the gdb.compile/ regressions, and this
> commit fixes the gdb.ada/ regressions.
> 

Hi Andrew,

thanks for working on this.

I've applied both patches and did a build and test run, and the 
regressions are fixed.

> I initially struggled to reproduce this issue.  The bug was reported
> against an openSUSE system, and in the end I was only able to
> reproduce it on a similar openSUSE system.  I suspect this is related
> to the original reporter, and myself, not having a particular debug
> package installed.
>

This is an interesting question, so I decided to investigate.

The first thing I found was that the alias system.crtl.malloc == malloc 
is present due to extra debug info in the executable.  FWIW, it comes 
from ./gcc/ada/libgnat/s-crtl.ads:
...
    function malloc (Size : size_t) return System.Address;
    pragma Import (C, malloc, "malloc");
...

In terms of debug info, the alias uses a DW_AT_linkage attribute to 
point to malloc.

I found a test-case in the testsuite (gdb.ada/lang_switch.exp) that also 
uses pragma import, but in a simpler setup: unlike here the alias points 
to a function in the same executable.  In case the c function is 
represented in the debug info, the alias target is found.  Otherwise, 
not.  This seems incorrect to me, so I filed a PR for this ( 
https://sourceware.org/bugzilla/show_bug.cgi?id=34627 ).

Then the question, is debug info missing for malloc?  That doesn't seem 
to be the case:
...
$ gdb -q -batch outputs/gdb.ada/funcall_ref/foo-all -ex start \
     -ex "set language c" -ex "p malloc"
   ...
$1 = {void *(size_t)} 0x7ffff7d63d2e <__GI___libc_malloc>
...

Looking at ada_alias_get_block_value, ISTM that using 
lookup_global_symbol means that it doesn't look beyond the exec 
containing the alias.  So in conclusion, I'd say the debug information 
is present, but ignored.

This might be due to a gdb bug, so I filed a PR ( 
https://sourceware.org/bugzilla/show_bug.cgi?id=34628 ).

I haven't reviewed the patch in detail, but the idea sounds good to.

Acked-By: Tom de Vries <tdevries@suse.de>

Thanks,
- Tom

> The tests in question need to allocate memory in the inferior.  To do
> this they call value_allocate_space_in_inferior, this calls
> find_function_in_inferior, which after commit 32090b27e92cb8fd makes a
> successful call to lookup_symbol.  This results in a backtrace like
> this:
> 
>    #0  ada_alias_get_block_value (sym=0x213da30) at ../../src/gdb/dwarf2/ada-imported.c:107
>    #1  0x0000000000db8775 in symbol::value_block (this=0x213da30) at ../../src/gdb/symtab.c:6619
>    #2  0x000000000045cc1f in remove_extra_symbols (syms=std::__debug::vector of length 2, capacity 2 = {...}) at ../../src/gdb/ada-lang.c:5182
>    #3  0x000000000045e236 in ada_lookup_symbol_list_worker (lookup_name=..., block=0x0, domain=..., full_search=true) at ../../src/gdb/ada-lang.c:5702
>    #4  0x000000000045e3c9 in ada_lookup_symbol_list (name=0x16a3ae4 "malloc", block=0x0, domain=...) at ../../src/gdb/ada-lang.c:5727
>    #5  0x000000000045e4bf in ada_lookup_symbol (name=0x16a3ae4 "malloc", block0=0x0, domain=...) at ../../src/gdb/ada-lang.c:5758
>    #6  0x000000000047b15a in ada_language::lookup_symbol_nonlocal (this=0x1bfd2c0 <ada_language_defn>, name=0x16a3ae4 "malloc", block=0x0, domain=...) at ../../src/gdb/ada-lang.c:13839
>    #7  0x0000000000dac991 in lookup_symbol_aux (name=0x16a3ae4 "malloc", match_type=symbol_name_match_type::FULL, block=0x0, domain=..., language=language_ada, is_a_field_of_this=0x0) at ../../src/gdb/symtab.c:2150
>    #8  0x0000000000dabfab in lookup_symbol_in_language (name=0x16a3ae4 "malloc", block=0x0, domain=..., lang=language_ada, is_a_field_of_this=0x0) at ../../src/gdb/symtab.c:1961
>    #9  0x0000000000dac042 in lookup_symbol (name=0x16a3ae4 "malloc", block=0x0, domain=..., is_a_field_of_this=0x0) at ../../src/gdb/symtab.c:1974
>    #10 0x0000000000f36346 in find_function_in_inferior (name=0x16a3ae4 "malloc", objf_p=0x7fffffffbef8) at ../../src/gdb/valops.c:122
>    #11 0x0000000000f36542 in value_allocate_space_in_inferior (len=8) at ../../src/gdb/valops.c:186
> 
> If GDB is unable to find the Ada alias for the function to be called
> then an exception is thrown.  This exception propagates all the way
> out of value_allocate_space_in_inferior, causing the allocation to
> fail, and as a consequence, the test to fail.
> 
> My thinking here is that, if the lookup_symbol call throws an
> exception then we should catch this in find_function_in_inferior and
> ignore it.  The find_function_in_inferior has a minimal symbol
> fallback path, so if the full symbol lookup throws an exception that
> doesn't mean we cannot try the minimal symbol path.
> 
> That's what I have implemented here.  With this done the gdb.ada/
> tests are now passing on my openSUSE test machine.
> 
> No new tests here as the original failure relies on being in an
> environment where there is insufficient debug information to find the
> Ada malloc function alias.
> 
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34602
> ---
>   gdb/valops.c | 31 ++++++++++++++++++++++---------
>   1 file changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/gdb/valops.c b/gdb/valops.c
> index 2ff15de7c68..a235a0ebe8d 100644
> --- a/gdb/valops.c
> +++ b/gdb/valops.c
> @@ -112,21 +112,34 @@ show_overload_resolution (struct ui_file *file, int from_tty,
>   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_FUNCTION_DOMAIN, nullptr);
> -  if (sym.symbol != nullptr)
> +  try
>       {
> -      msymbol = find_gnu_ifunc (sym.symbol);
> -      if (msymbol.minsym == nullptr)
> +      block_symbol sym = lookup_symbol (name, nullptr, SEARCH_FUNCTION_DOMAIN,
> +					nullptr);
> +
> +      if (sym.symbol != nullptr)
>   	{
> -	  if (objf_p != nullptr)
> -	    *objf_p = sym.symbol->objfile ();
> -	  return value_of_variable (sym.symbol, sym.block);
> +	  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
> +  catch (const gdb_exception_error &)
> +    {
> +      /* Ignore the error.  If there's a problem looking for the full
> +	 symbol then we shouldn't give up, we should fall back to
> +	 looking for the minimal symbol.  */
> +    }
> +
> +  /* If we didn't find an IFunc related minimal symbol above, then
> +     look for a suitable minimal symbol now.  */
> +  if (msymbol.minsym == nullptr)
>       msymbol = lookup_minimal_symbol (current_program_space, name);
>   
>     if (msymbol.minsym != nullptr)

Re: [PATCH 2/2] gdb: catch some exceptions in find_function_in_inferior

[Tom Tromey]

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

Tom> The first thing I found was that the alias system.crtl.malloc ==
Tom> malloc is present due to extra debug info in the executable.  FWIW, it
Tom> comes from ./gcc/ada/libgnat/s-crtl.ads:
Tom> ...
Tom>    function malloc (Size : size_t) return System.Address;
Tom>    pragma Import (C, malloc, "malloc");
Tom> ...

FWIW doing name lookups in Ada is weird, because Ada defaults to wild
matching.  If you want to just find the C malloc, you have to look for
"<malloc>".

So, if the code is going via any language-specific lookup route (I
didn't dig in but it probably is), then you can easily find the wrong
function.

It would be nice to fix this, but it's complicated.

Alternatively some kind of language-neutral or "force it to use C"
approach could be implemented.

Tom> In case the c function
Tom> is represented in the debug info, the alias target is found.
Tom> Otherwise, not.  This seems incorrect to me, so I filed a PR for this
Tom> ( https://sourceware.org/bugzilla/show_bug.cgi?id=34627 ).

I commented in the bug, but this is unavoidable.  The error is thrown
because gdb wants to find a function block -- but if the alias target
doesn't have debug info, no such block is available.

Tom> Looking at ada_alias_get_block_value, ISTM that using
Tom> lookup_global_symbol means that it doesn't look beyond the exec
Tom> containing the alias.  So in conclusion, I'd say the debug information
Tom> is present, but ignored.

This part seems strange in that lookup_global_symbol should search all
objfiles.  But I wonder if instead it's finding the wrong symbol due to
wild matching.  Anyway I suspect something else weird is going on.

Tom> This might be due to a gdb bug, so I filed a PR (
Tom> https://sourceware.org/bugzilla/show_bug.cgi?id=34628 ).

Tom

Re: [PATCH 0/2] Fix regressions after find_function_in_inferior changes

[Tom Tromey]

Andrew> This series fixes these regressions.  The gdb.compile/ tests are fixed
Andrew> by the first patch and the gdb.ada/ tests by the second.

Thanks.
Approved-By: Tom Tromey <tom@tromey.com>

Tom