Re: [PATCH 1/1] gdb: Preserve IFUNC marker when finding inferior functions

[Muhammad Kamran <muhammad.kamran@arm.com>]

Hi Andrew,

Thanks for the review.

On 24/06/2026 16:53, Andrew Burgess wrote:
> Muhammad Kamran <muhammad.kamran@arm.com> writes:
> 
>> GDB calls find_function_in_inferior ("malloc") when expression
>> evaluation needs to allocate memory in the inferior, e.g. for string
>> literal arguments.
>>
>> The minimal-symbol fallback created a synthetic ordinary function
>> pointer from msymbol.value_address ().  If the symbol was a GNU IFUNC,
>> this discarded the IFUNC marker, so call_function_by_hand did not
>> resolve the symbol before calling it.
>>
>> Use find_minsym_type_and_address to classify the minimal symbol and
>> propagate the GNU IFUNC marker to the synthetic function type.  This
>> keeps the existing fallback return type while allowing inferior calls
>> through IFUNC symbols to be resolved correctly.
>> ---
>>   gdb/valops.c | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> Is it possible to create a test for this issue that would fail on other
> targets?  There's gdb.base/gnu-ifunc.exp, from the patch I'm wondering
> if all that would be needed is to place an ifunc function in a library,
> and compile the library without debug information?  It's not super clear
> from your description the exact steps that are needed to trigger this
> bug.

Yes, this can be tested.  I added a regression test in v2 to
gdb.base/gnu-ifunc.exp.  The test defines malloc as a GNU IFUNC in a
no-debug object, and links it with a small debug test program.  The test
then evaluates an inferior call with a string literal argument.  Copying
that string literal into the inferior forces GDB through
find_function_in_inferior ("malloc"), which exercises the minimal-symbol
fallback.

> 
>>
>> diff --git a/gdb/valops.c b/gdb/valops.c
>> index ab6fd5079e1..7d305871efc 100644
>> --- a/gdb/valops.c
>> +++ b/gdb/valops.c
>> @@ -133,11 +133,15 @@ find_function_in_inferior (const char *name, struct objfile **objf_p)
>>   	  struct gdbarch *gdbarch = objfile->arch ();
>>   
>>   	  struct type *type;
>> +	  struct type *resolved_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 ();
>> +	  resolved_type = find_minsym_type_and_address (msymbol.minsym, objfile,
>> +							&maddr);
>> +	  if (resolved_type->is_gnu_ifunc ())
>> +	    type->target_type ()->set_is_gnu_ifunc (true);
> 
> There are other places in GDB where we use lookup_function_type, could
> these also run into this issue?  It would be nice if the description
> explained why other similar places in GDB don't need changing if that's
> the case.

The issue is not lookup_function_type itself.  The bug fixed here is the
specific find_function_in_inferior minimal-symbol fallback: it had
already found a minimal symbol, but then built a synthetic callable
value without carrying over the symbol's STT_GNU_IFUNC classification.

I did not find another direct lookup_function_type caller with the same
minimal-symbol fallback pattern.  Some code does build ordinary function
pointer types for known non-IFUNC helper paths, so I have kept this
patch limited to the path needed by find_function_in_inferior.

Thanks,
Kamran

> 
> Thanks,
> Andrew
> 
> 
>>   
>>   	  if (objf_p)
>>   	    *objf_p = objfile;
>> -- 
>> 2.43.0
>