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

[Tom de Vries <tdevries@suse.de>]

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)