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

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

[Muhammad Kamran]

This patch fixes a GDB inferior-call issue exposed by malloc being a GNU
IFUNC in glibc on AArch64.  The underlying problem is not AArch64-specific:
it can affect any inferior helper found through find_function_in_inferior's
minimal-symbol fallback when that helper is a GNU IFUNC.

GDB calls find_function_in_inferior ("malloc") when expression evaluation
needs to allocate memory in the inferior, for example for string literal
arguments.  In the minimal-symbol fallback, GDB created a synthetic ordinary
function pointer from the minimal symbol address.  If the symbol was a GNU
IFUNC, this lost the IFUNC marker, so call_function_by_hand did not resolve
the symbol before calling it.

The patch uses find_minsym_type_and_address to classify the minimal symbol
and propagates the IFUNC marker to the synthetic function type when needed.
The existing fallback return type is unchanged.

Changes since v1:
	* Reword the commit message.
	* Add a test case using a no-debug IFUNC malloc to exercise the
	  minimal-symbol fallback.

Muhammad Kamran (1):
  gdb: Preserve IFUNC marker when finding inferior functions

 .../gdb.base/gnu-ifunc-inferior-call-malloc.c | 27 +++++++++++
 .../gdb.base/gnu-ifunc-inferior-call.c        | 45 +++++++++++++++++++
 gdb/testsuite/gdb.base/gnu-ifunc.exp          | 40 +++++++++++++++++
 gdb/valops.c                                  |  6 ++-
 4 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.base/gnu-ifunc-inferior-call-malloc.c
 create mode 100644 gdb/testsuite/gdb.base/gnu-ifunc-inferior-call.c

-- 
2.43.0

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

[Muhammad Kamran]

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.base/gnu-ifunc-inferior-call-malloc.c | 27 +++++++++++
 .../gdb.base/gnu-ifunc-inferior-call.c        | 45 +++++++++++++++++++
 gdb/testsuite/gdb.base/gnu-ifunc.exp          | 40 +++++++++++++++++
 gdb/valops.c                                  |  6 ++-
 4 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.base/gnu-ifunc-inferior-call-malloc.c
 create mode 100644 gdb/testsuite/gdb.base/gnu-ifunc-inferior-call.c

diff --git a/gdb/testsuite/gdb.base/gnu-ifunc-inferior-call-malloc.c b/gdb/testsuite/gdb.base/gnu-ifunc-inferior-call-malloc.c
new file mode 100644
index 00000000000..2547fee20a9
--- /dev/null
+++ b/gdb/testsuite/gdb.base/gnu-ifunc-inferior-call-malloc.c
@@ -0,0 +1,27 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2026 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+#include <stddef.h>
+
+extern void *dummy_malloc (size_t size);
+
+static void *(*resolve_malloc (void)) (size_t)
+{
+  return dummy_malloc;
+}
+
+void *malloc (size_t size) __attribute__ ((ifunc ("resolve_malloc")));
diff --git a/gdb/testsuite/gdb.base/gnu-ifunc-inferior-call.c b/gdb/testsuite/gdb.base/gnu-ifunc-inferior-call.c
new file mode 100644
index 00000000000..3b70811b69b
--- /dev/null
+++ b/gdb/testsuite/gdb.base/gnu-ifunc-inferior-call.c
@@ -0,0 +1,45 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2026 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+#include <stddef.h>
+
+static char arena[32];
+const char *str;
+
+int
+str_in_arena (void)
+{
+  return str == arena;
+}
+
+void *
+dummy_malloc (size_t size)
+{
+  return arena;
+}
+
+void
+get_string (const char *s)
+{
+  str = s;
+}
+
+int
+main (void)
+{
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.base/gnu-ifunc.exp b/gdb/testsuite/gdb.base/gnu-ifunc.exp
index e6389102ae3..85f57071140 100644
--- a/gdb/testsuite/gdb.base/gnu-ifunc.exp
+++ b/gdb/testsuite/gdb.base/gnu-ifunc.exp
@@ -25,6 +25,11 @@ set libsrc ${libfile}.c
 set final_file "${testfile}-final"
 set final_src ${final_file}.c
 
+set infcall_file "${testfile}-inferior-call"
+set infcall_src ${infcall_file}.c
+set infcall_malloc_file "${testfile}-inferior-call-malloc"
+set infcall_malloc_src ${infcall_malloc_file}.c
+
 # Return the binary suffix appended to program and library names to
 # make each testcase variant unique.
 proc make_binsuffix {resolver_attr resolver_debug final_debug} {
@@ -356,6 +361,39 @@ proc misc_tests {resolver_attr resolver_debug final_debug} {
     }
 }
 
+# Test that GDB resolves a GNU IFUNC minimal symbol when it uses
+# find_function_in_inferior to make an internal inferior call.  String
+# literals are copied into the inferior with a call to malloc, so a
+# no-debug IFUNC malloc exercises the minimal-symbol fallback.
+
+proc_with_prefix test_inferior_call {} {
+    global srcdir subdir
+    global infcall_file infcall_src
+    global infcall_malloc_file infcall_malloc_src
+
+    set executable $infcall_file
+    set binfile [standard_output_file $executable]
+    set malloc_obj [standard_output_file ${infcall_malloc_file}.o]
+
+    if { [gdb_compile ${srcdir}/${subdir}/${infcall_malloc_src} \
+	      $malloc_obj object {}] != ""
+	 || [gdb_compile [list ${srcdir}/${subdir}/${infcall_src} \
+			      $malloc_obj] \
+		 $binfile executable {debug}] != "" } {
+	untested "failed to compile inferior call testcase"
+	return
+    }
+
+    clean_restart $executable
+    if {![runto_main]} {
+	return
+    }
+
+    gdb_test "print (get_string (\"hello-ifunc\"), str_in_arena ())" \
+	" = 1" \
+	"internal call resolves no-debug IFUNC malloc"
+}
+
 # Test all the combinations of:
 #
 # - An ifunc resolver with the same name as the ifunc symbol vs an
@@ -379,6 +417,8 @@ foreach_with_prefix resolver_attr {0 1} {
     }
 }
 
+test_inferior_call
+
 # Test statically linked ifunc resolving during inferior start.
 # https://bugzilla.redhat.com/show_bug.cgi?id=624967
 
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);
 
 	  if (objf_p)
 	    *objf_p = objfile;
-- 
2.43.0

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

[Simon Marchi]

> @@ -356,6 +361,39 @@ proc misc_tests {resolver_attr resolver_debug final_debug} {
>      }
>  }
>  
> +# Test that GDB resolves a GNU IFUNC minimal symbol when it uses
> +# find_function_in_inferior to make an internal inferior call.  String
> +# literals are copied into the inferior with a call to malloc, so a
> +# no-debug IFUNC malloc exercises the minimal-symbol fallback.
> +
> +proc_with_prefix test_inferior_call {} {
> +    global srcdir subdir
> +    global infcall_file infcall_src
> +    global infcall_malloc_file infcall_malloc_src
> +
> +    set executable $infcall_file
> +    set binfile [standard_output_file $executable]
> +    set malloc_obj [standard_output_file ${infcall_malloc_file}.o]
> +
> +    if { [gdb_compile ${srcdir}/${subdir}/${infcall_malloc_src} \
> +	      $malloc_obj object {}] != ""
> +	 || [gdb_compile [list ${srcdir}/${subdir}/${infcall_src} \
> +			      $malloc_obj] \
> +		 $binfile executable {debug}] != "" } {
> +	untested "failed to compile inferior call testcase"
> +	return
> +    }

I think that the test should also cover the case where we do have debug
info.  However, the gdb.base/gnu-ifunc.exp test is already written in
a such a way that it tests all imaginable combinations:

# Test all the combinations of:
#
# - An ifunc resolver with the same name as the ifunc symbol vs an
#   ifunc resolver with a different name as the ifunc symbol.
#
# - ifunc resolver compiled with and without debug info.  This ensures
#   that GDB understands that a function not a regular function by
#   looking at the STT_GNU_IFUNC type in the elf symbols.  DWARF has
#   no way to express the STT_GNU_IFUNC type.
#
# - ifunc target function (resolved) compiled with and without debug
#   info.
foreach_with_prefix resolver_attr {0 1} {
    foreach_with_prefix resolver_debug {0 1} {
	foreach_with_prefix final_debug {0 1} {
	    if { [build $resolver_attr $resolver_debug $final_debug] != 0 } {
		misc_tests $resolver_attr $resolver_debug $final_debug
		set-break $resolver_attr $resolver_debug $final_debug
	    }
	}
    }
}

Could you somehow hook the new infcall tests into that, so that we also
test infcalls in all imaginable situations.

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

Calling find_minsym_type_and_address just to know if the minsym is an
ifunc seems rather heavyweight for nothing.  Can't we just check that
the minsym type is mst_text_gnu_ifunc?

I assume that the `maddr` output by find_minsym_type_and_address would
always be equal to `msymbol.value_address ()`.

Side-note: this "find_function_in_inferior" (at least the fallback)
really assumes that we are looking for a function returning "char *", so
that function seems misnamed (it could easily be mis-used).

Simon

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

[Muhammad Kamran]

Hi Simon,

On 25/06/2026 21:05, Simon Marchi wrote:
> 
>> @@ -356,6 +361,39 @@ proc misc_tests {resolver_attr resolver_debug final_debug} {
>>       }
>>   }
>>   
>> +# Test that GDB resolves a GNU IFUNC minimal symbol when it uses
>> +# find_function_in_inferior to make an internal inferior call.  String
>> +# literals are copied into the inferior with a call to malloc, so a
>> +# no-debug IFUNC malloc exercises the minimal-symbol fallback.
>> +
>> +proc_with_prefix test_inferior_call {} {
>> +    global srcdir subdir
>> +    global infcall_file infcall_src
>> +    global infcall_malloc_file infcall_malloc_src
>> +
>> +    set executable $infcall_file
>> +    set binfile [standard_output_file $executable]
>> +    set malloc_obj [standard_output_file ${infcall_malloc_file}.o]
>> +
>> +    if { [gdb_compile ${srcdir}/${subdir}/${infcall_malloc_src} \
>> +	      $malloc_obj object {}] != ""
>> +	 || [gdb_compile [list ${srcdir}/${subdir}/${infcall_src} \
>> +			      $malloc_obj] \
>> +		 $binfile executable {debug}] != "" } {
>> +	untested "failed to compile inferior call testcase"
>> +	return
>> +    }
> 
> I think that the test should also cover the case where we do have debug
> info.  However, the gdb.base/gnu-ifunc.exp test is already written in
> a such a way that it tests all imaginable combinations:
> 
> # Test all the combinations of:
> #
> # - An ifunc resolver with the same name as the ifunc symbol vs an
> #   ifunc resolver with a different name as the ifunc symbol.
> #
> # - ifunc resolver compiled with and without debug info.  This ensures
> #   that GDB understands that a function not a regular function by
> #   looking at the STT_GNU_IFUNC type in the elf symbols.  DWARF has
> #   no way to express the STT_GNU_IFUNC type.
> #
> # - ifunc target function (resolved) compiled with and without debug
> #   info.
> foreach_with_prefix resolver_attr {0 1} {
>      foreach_with_prefix resolver_debug {0 1} {
> 	foreach_with_prefix final_debug {0 1} {
> 	    if { [build $resolver_attr $resolver_debug $final_debug] != 0 } {
> 		misc_tests $resolver_attr $resolver_debug $final_debug
> 		set-break $resolver_attr $resolver_debug $final_debug
> 	    }
> 	}
>      }
> }
> 
> Could you somehow hook the new infcall tests into that, so that we also
> test infcalls in all imaginable situations.
> 

I've extended the test to run through the existing
resolver_attr/resolver_debug/final_debug matrix.  With only the test
change, the new inferior-call test fails in all eight combinations on
AArch64, so the issue is wider than the original no-debug minimal-symbol
case.  I'll work on the patch accordingly and post a new version once I
have the patch ready.

>> 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);
> 
> Calling find_minsym_type_and_address just to know if the minsym is an
> ifunc seems rather heavyweight for nothing.  Can't we just check that
> the minsym type is mst_text_gnu_ifunc?
> 

I used find_minsym_type_and_address because it keeps
find_function_in_inferior consistent with normal minimal-symbol
evaluation.  It also handles function-descriptor symbols:
mst_data_gnu_ifunc may have a descriptor address as its value, and
find_minsym_type_and_address can convert that to the code address and
reclassify it as mst_text_gnu_ifunc.  A direct mst_text_gnu_ifunc check
would miss that case, and value_address () could be the descriptor
address rather than the callable address.
For reference: gdb/minsyms.c:1594 has:
   /* The minimal symbol might point to a function descriptor;
      resolve it to the actual code address instead.  */

If you still prefer avoiding find_minsym_type_and_address here, I think
we would need a helper that shares the same descriptor/address handling,
rather than checking only mst_text_gnu_ifunc.

Please share your thoughts.

Thanks,
Kamran

> I assume that the `maddr` output by find_minsym_type_and_address would
> always be equal to `msymbol.value_address ()`.
> 
> Side-note: this "find_function_in_inferior" (at least the fallback)
> really assumes that we are looking for a function returning "char *", so
> that function seems misnamed (it could easily be mis-used).
> 
> Simon

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

[Simon Marchi]

On 2026-06-26 05:24, Muhammad Kamran wrote:
> Hi Simon,
> 
> On 25/06/2026 21:05, Simon Marchi wrote:
>>
>>> @@ -356,6 +361,39 @@ proc misc_tests {resolver_attr resolver_debug final_debug} {
>>>       }
>>>   }
>>>   +# Test that GDB resolves a GNU IFUNC minimal symbol when it uses
>>> +# find_function_in_inferior to make an internal inferior call.  String
>>> +# literals are copied into the inferior with a call to malloc, so a
>>> +# no-debug IFUNC malloc exercises the minimal-symbol fallback.
>>> +
>>> +proc_with_prefix test_inferior_call {} {
>>> +    global srcdir subdir
>>> +    global infcall_file infcall_src
>>> +    global infcall_malloc_file infcall_malloc_src
>>> +
>>> +    set executable $infcall_file
>>> +    set binfile [standard_output_file $executable]
>>> +    set malloc_obj [standard_output_file ${infcall_malloc_file}.o]
>>> +
>>> +    if { [gdb_compile ${srcdir}/${subdir}/${infcall_malloc_src} \
>>> +          $malloc_obj object {}] != ""
>>> +     || [gdb_compile [list ${srcdir}/${subdir}/${infcall_src} \
>>> +                  $malloc_obj] \
>>> +         $binfile executable {debug}] != "" } {
>>> +    untested "failed to compile inferior call testcase"
>>> +    return
>>> +    }
>>
>> I think that the test should also cover the case where we do have debug
>> info.  However, the gdb.base/gnu-ifunc.exp test is already written in
>> a such a way that it tests all imaginable combinations:
>>
>> # Test all the combinations of:
>> #
>> # - An ifunc resolver with the same name as the ifunc symbol vs an
>> #   ifunc resolver with a different name as the ifunc symbol.
>> #
>> # - ifunc resolver compiled with and without debug info.  This ensures
>> #   that GDB understands that a function not a regular function by
>> #   looking at the STT_GNU_IFUNC type in the elf symbols.  DWARF has
>> #   no way to express the STT_GNU_IFUNC type.
>> #
>> # - ifunc target function (resolved) compiled with and without debug
>> #   info.
>> foreach_with_prefix resolver_attr {0 1} {
>>      foreach_with_prefix resolver_debug {0 1} {
>>     foreach_with_prefix final_debug {0 1} {
>>         if { [build $resolver_attr $resolver_debug $final_debug] != 0 } {
>>         misc_tests $resolver_attr $resolver_debug $final_debug
>>         set-break $resolver_attr $resolver_debug $final_debug
>>         }
>>     }
>>      }
>> }
>>
>> Could you somehow hook the new infcall tests into that, so that we also
>> test infcalls in all imaginable situations.
>>
> 
> I've extended the test to run through the existing
> resolver_attr/resolver_debug/final_debug matrix.  With only the test
> change, the new inferior-call test fails in all eight combinations on
> AArch64, so the issue is wider than the original no-debug minimal-symbol
> case.  I'll work on the patch accordingly and post a new version once I
> have the patch ready.
> 
>>> 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);
>>
>> Calling find_minsym_type_and_address just to know if the minsym is an
>> ifunc seems rather heavyweight for nothing.  Can't we just check that
>> the minsym type is mst_text_gnu_ifunc?
>>
> 
> I used find_minsym_type_and_address because it keeps
> find_function_in_inferior consistent with normal minimal-symbol
> evaluation.  It also handles function-descriptor symbols:
> mst_data_gnu_ifunc may have a descriptor address as its value, and
> find_minsym_type_and_address can convert that to the code address and
> reclassify it as mst_text_gnu_ifunc.  A direct mst_text_gnu_ifunc check
> would miss that case, and value_address () could be the descriptor
> address rather than the callable address.
> For reference: gdb/minsyms.c:1594 has:
>   /* The minimal symbol might point to a function descriptor;
>      resolve it to the actual code address instead.  */
> 
> If you still prefer avoiding find_minsym_type_and_address here, I think
> we would need a helper that shares the same descriptor/address handling,
> rather than checking only mst_text_gnu_ifunc.

If the descriptor to actual address translation is really needed, then
find_minsym_type_and_address sounds fine.

Simon

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

[Muhammad Kamran]

Hi Simon,

On 26/06/2026 15:20, Simon Marchi wrote:
> 
> 
> On 2026-06-26 05:24, Muhammad Kamran wrote:
>> Hi Simon,
>>
>> On 25/06/2026 21:05, Simon Marchi wrote:
>>>
>>>> @@ -356,6 +361,39 @@ proc misc_tests {resolver_attr resolver_debug final_debug} {
>>>>        }
>>>>    }
>>>>    +# Test that GDB resolves a GNU IFUNC minimal symbol when it uses
>>>> +# find_function_in_inferior to make an internal inferior call.  String
>>>> +# literals are copied into the inferior with a call to malloc, so a
>>>> +# no-debug IFUNC malloc exercises the minimal-symbol fallback.
>>>> +
>>>> +proc_with_prefix test_inferior_call {} {
>>>> +    global srcdir subdir
>>>> +    global infcall_file infcall_src
>>>> +    global infcall_malloc_file infcall_malloc_src
>>>> +
>>>> +    set executable $infcall_file
>>>> +    set binfile [standard_output_file $executable]
>>>> +    set malloc_obj [standard_output_file ${infcall_malloc_file}.o]
>>>> +
>>>> +    if { [gdb_compile ${srcdir}/${subdir}/${infcall_malloc_src} \
>>>> +          $malloc_obj object {}] != ""
>>>> +     || [gdb_compile [list ${srcdir}/${subdir}/${infcall_src} \
>>>> +                  $malloc_obj] \
>>>> +         $binfile executable {debug}] != "" } {
>>>> +    untested "failed to compile inferior call testcase"
>>>> +    return
>>>> +    }
>>>
>>> I think that the test should also cover the case where we do have debug
>>> info.  However, the gdb.base/gnu-ifunc.exp test is already written in
>>> a such a way that it tests all imaginable combinations:
>>>
>>> # Test all the combinations of:
>>> #
>>> # - An ifunc resolver with the same name as the ifunc symbol vs an
>>> #   ifunc resolver with a different name as the ifunc symbol.
>>> #
>>> # - ifunc resolver compiled with and without debug info.  This ensures
>>> #   that GDB understands that a function not a regular function by
>>> #   looking at the STT_GNU_IFUNC type in the elf symbols.  DWARF has
>>> #   no way to express the STT_GNU_IFUNC type.
>>> #
>>> # - ifunc target function (resolved) compiled with and without debug
>>> #   info.
>>> foreach_with_prefix resolver_attr {0 1} {
>>>       foreach_with_prefix resolver_debug {0 1} {
>>>      foreach_with_prefix final_debug {0 1} {
>>>          if { [build $resolver_attr $resolver_debug $final_debug] != 0 } {
>>>          misc_tests $resolver_attr $resolver_debug $final_debug
>>>          set-break $resolver_attr $resolver_debug $final_debug
>>>          }
>>>      }
>>>       }
>>> }
>>>
>>> Could you somehow hook the new infcall tests into that, so that we also
>>> test infcalls in all imaginable situations.
>>>
>>
>> I've extended the test to run through the existing
>> resolver_attr/resolver_debug/final_debug matrix.  With only the test
>> change, the new inferior-call test fails in all eight combinations on
>> AArch64, so the issue is wider than the original no-debug minimal-symbol
>> case.  I'll work on the patch accordingly and post a new version once I
>> have the patch ready.
>>
>>>> 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);
>>>
>>> Calling find_minsym_type_and_address just to know if the minsym is an
>>> ifunc seems rather heavyweight for nothing.  Can't we just check that
>>> the minsym type is mst_text_gnu_ifunc?
>>>

I posted a v3 using the direct minimal-symbol type check you suggested.
That is better here because find_function_in_inferior only needs to
preserve the IFUNC marker on the synthetic function type; it does not
need to redo minimal-symbol address/type resolution.

The descriptor case is already handled later in the normal inferior-call
path.  find_function_in_inferior creates a pointer-to-function value,
and find_function_addr handles such values by calling
gdbarch_convert_from_func_ptr_addr before IFUNC resolution.

Thanks,
Kamran

>>
>> I used find_minsym_type_and_address because it keeps
>> find_function_in_inferior consistent with normal minimal-symbol
>> evaluation.  It also handles function-descriptor symbols:
>> mst_data_gnu_ifunc may have a descriptor address as its value, and
>> find_minsym_type_and_address can convert that to the code address and
>> reclassify it as mst_text_gnu_ifunc.  A direct mst_text_gnu_ifunc check
>> would miss that case, and value_address () could be the descriptor
>> address rather than the callable address.
>> For reference: gdb/minsyms.c:1594 has:
>>    /* The minimal symbol might point to a function descriptor;
>>       resolve it to the actual code address instead.  */
>>
>> If you still prefer avoiding find_minsym_type_and_address here, I think
>> we would need a helper that shares the same descriptor/address handling,
>> rather than checking only mst_text_gnu_ifunc.
> 
> If the descriptor to actual address translation is really needed, then
> find_minsym_type_and_address sounds fine.
> 



> Simon

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

[Florian Weimer]

* Muhammad Kamran:

> GDB calls find_function_in_inferior ("malloc") when expression
> evaluation needs to allocate memory in the inferior, e.g. for string
> literal arguments.

So this looks fairly nasty.  This looks fairly harmless as far as GDB
expressions go:

> +    gdb_test "print (get_string (\"hello-ifunc\"), str_in_arena ())" \

We can actually detect the GDB call and glibc and do the right thing:

  [PATCH 0/2] Work around GDB bug overwriting __libc_malloc
  <https://inbox.sourceware.org/libc-alpha/cover.1782766548.git.fweimer@redhat.com/>

Of course the GDB bug still needs fixing.

By the way, I don't think there is a safe way for GDB to call IFUNC
resolvers.  IFUNC resolvers in glibc may assume the presence of extra
data that was not there in the initial definition of the interface.
This shouldn't matter for malloc: elf_gnu_ifunc_resolve_by_got should
always be able obtain the pre-relocated address (except before
relocation has happened).

Does your patch change the behavior and output of this?

(gdb) print strcpy
$1 = {<text gnu-indirect-function variable, no debug info>} 0x7ffff7e0b8f0 <strcpy_ifunc>

Currently, the workaround looks like this:

(gdb) print dlsym(0, "strcpy")
$2 = (void *) 0x7ffff7ecb970 <__strcpy_avx2>

Maybe going through dlsym would also be the right way to do the inferior
calls involving IFUNC resolvers.  We can also provide a symbol that GDB
can call to make the IFUNC resolver call, given its handler address.

Thanks,
Florian

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

[Yury Khrustalev]

* Florian

On Mon, Jun 29, 2026 at 11:11:07PM +0200, Florian Weimer wrote:
> * Muhammad Kamran:
> 
> > GDB calls find_function_in_inferior ("malloc") when expression
> > evaluation needs to allocate memory in the inferior, e.g. for string
> > literal arguments.
> 
> So this looks fairly nasty.  This looks fairly harmless as far as GDB
> expressions go:
> 
> > +    gdb_test "print (get_string (\"hello-ifunc\"), str_in_arena ())" \
> 
> We can actually detect the GDB call and glibc and do the right thing:
> 
>   [PATCH 0/2] Work around GDB bug overwriting __libc_malloc
>   <https://inbox.sourceware.org/libc-alpha/cover.1782766548.git.fweimer@redhat.com/>

There is another work-around that is already present: Glibc can be
configured with --disable-multi-arch and this will disable all ifuncs
including malloc ones. Sorry, I forgot about it earlier. This might not
be ideal if you intend to debug these ifuncs in Glibc, but it's probably
the best way for a broken GDB.

Thanks,
Yury

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

[Yury Khrustalev]

On Mon, Jun 29, 2026 at 11:11:07PM +0200, Florian Weimer wrote:
> * Muhammad Kamran:
> 
> > GDB calls find_function_in_inferior ("malloc") when expression
> > evaluation needs to allocate memory in the inferior, e.g. for string
> > literal arguments.
> 
> ...
> 
> Maybe going through dlsym would also be the right way to do the inferior
> calls involving IFUNC resolvers.  We can also provide a symbol that GDB
> can call to make the IFUNC resolver call, given its handler address.

Perhaps we should add an alias to __libc_malloc (and other malloc
functions that GDB needs) for GDB, something like `__gdb_malloc`
that would become Glibc's ABI for GDB? This is not ideal of course
as GDB would need to look for this new symbol and than still fallback
to 'malloc' to support other non-Glibc runtimes.

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

[Wilco Dijkstra]

Hi,

> Perhaps we should add an alias to __libc_malloc (and other malloc
> functions that GDB needs) for GDB, something like `__gdb_malloc`
> that would become Glibc's ABI for GDB? This is not ideal of course
> as GDB would need to look for this new symbol and than still fallback
> to 'malloc' to support other non-Glibc runtimes.

If the debugger just randomly changes malloc state, it's impossible to
debug memory or pointer issues...

So I don't believe it should use malloc or a different helper. String
arguments can be placed on the stack just like any other arguments
(within a reasonable limit - anything too large could simply be refused
just like a call with 1M arguments).

Cheers,
Wilco

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

[Florian Weimer]

* Wilco Dijkstra:

> Hi,
>
>> Perhaps we should add an alias to __libc_malloc (and other malloc
>> functions that GDB needs) for GDB, something like `__gdb_malloc`
>> that would become Glibc's ABI for GDB? This is not ideal of course
>> as GDB would need to look for this new symbol and than still fallback
>> to 'malloc' to support other non-Glibc runtimes.
>
> If the debugger just randomly changes malloc state, it's impossible to
> debug memory or pointer issues...
>
> So I don't believe it should use malloc or a different helper. String
> arguments can be placed on the stack just like any other arguments
> (within a reasonable limit - anything too large could simply be refused
> just like a call with 1M arguments).

I think for literals, most uses expect different life-times.

Does GDB ever free the copy of the literal?

Thanks,
Florian

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

[Tom Tromey]

>>>>> "Florian" == Florian Weimer <fweimer@redhat.com> writes:

Florian> Does GDB ever free the copy of the literal?

No.  I think there's a bug open about this but it's never seemed
important to fix.

Tom

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

[Florian Weimer]

* Tom Tromey:

>>>>>> "Florian" == Florian Weimer <fweimer@redhat.com> writes:
>
> Florian> Does GDB ever free the copy of the literal?
>
> No.  I think there's a bug open about this but it's never seemed
> important to fix.

This is perhaps the main reason for using malloc?  The proper lifetime
of the literal is unclear, so it can never be deallocated, and using
malloc at least avoids wasting a full page?

Thanks,
Florian

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

[Tom Tromey]

>>>>> Florian Weimer <fweimer@redhat.com> writes:

Florian> Does GDB ever free the copy of the literal?

>> No.  I think there's a bug open about this but it's never seemed
>> important to fix.

> This is perhaps the main reason for using malloc?  The proper lifetime
> of the literal is unclear, so it can never be deallocated, and using
> malloc at least avoids wasting a full page?

gdb has used malloc for this since well before I worked on gdb, like
decades before.  Probably the rationale has been lost.

Anyway, yes, I think one reason this isn't fixed is that it's not clear
when the memory ought to freed.  Also AFAIK this has never been a real
issue in practice.

Tom

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

[Muhammad Kamran]

Hi Florian,
>> GDB calls find_function_in_inferior ("malloc") when expression
>> evaluation needs to allocate memory in the inferior, e.g. for string
>> literal arguments.
> 
> So this looks fairly nasty.  This looks fairly harmless as far as GDB
> expressions go:
> 
>> +    gdb_test "print (get_string (\"hello-ifunc\"), str_in_arena ())" \
> 
> We can actually detect the GDB call and glibc and do the right thing:
> 
>    [PATCH 0/2] Work around GDB bug overwriting __libc_malloc
>    <https://inbox.sourceware.org/libc-alpha/cover.1782766548.git.fweimer@redhat.com/>
> 
> Of course the GDB bug still needs fixing.
> 
> By the way, I don't think there is a safe way for GDB to call IFUNC
> resolvers.  IFUNC resolvers in glibc may assume the presence of extra
> data that was not there in the initial definition of the interface.
> This shouldn't matter for malloc: elf_gnu_ifunc_resolve_by_got should
> always be able obtain the pre-relocated address (except before
> relocation has happened).

Yes.  GDB should prefer the cache/GOT path and avoid resolver calls
where possible.  The patch does not make resolver calls safer or add a
new resolver-calling mechanism; it just preserves the IFUNC marker so
the existing IFUNC resolution path is used instead of calling the
resolver address as though it were malloc itself.

> 
> Does your patch change the behavior and output of this?
> 
> (gdb) print strcpy
> $1 = {<text gnu-indirect-function variable, no debug info>} 0x7ffff7e0b8f0 <strcpy_ifunc>
> 
> Currently, the workaround looks like this:
> 
> (gdb) print dlsym(0, "strcpy")
> $2 = (void *) 0x7ffff7ecb970 <__strcpy_avx2>
> 

No.  `print strcpy` uses the normal minimal-symbol evaluation path,
which already classifies GNU IFUNC symbols.  The patch only changes
find_function_in_inferior's internal fallback path.

I verified this on x86-64 with the patch applied and the output
remains unchanged.

Thanks,
Kamran

> Maybe going through dlsym would also be the right way to do the inferior
> calls involving IFUNC resolvers.  We can also provide a symbol that GDB
> can call to make the IFUNC resolver call, given its handler address.
> 
> Thanks,
> Florian
> 

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

[Wilco Dijkstra]

Hi Muhammad,

> Yes.  GDB should prefer the cache/GOT path and avoid resolver calls
> where possible.  The patch does not make resolver calls safer or add a
> new resolver-calling mechanism; it just preserves the IFUNC marker so
> the existing IFUNC resolution path is used instead of calling the
> resolver address as though it were malloc itself.

Indeed - while the patch works for now as a workaround, directly calling
ifunc resolvers without following the ifunc ABI does not work. GDB only
passes HWCAP as the first argument, so the resolver may return different
functions due to the set of HWCAP values given not being identical between
GDB and GLIBC (ie. It could call the wrong malloc implementation that was
not selected or initialized).

So the best option is to call dlsym() as Florian suggested.

Cheers,
Wilco

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

[Simon Marchi]

On 6/30/26 11:29 AM, Wilco Dijkstra wrote:
> Hi Muhammad,
> 
>> Yes.  GDB should prefer the cache/GOT path and avoid resolver calls
>> where possible.  The patch does not make resolver calls safer or add a
>> new resolver-calling mechanism; it just preserves the IFUNC marker so
>> the existing IFUNC resolution path is used instead of calling the
>> resolver address as though it were malloc itself.
> 
> Indeed - while the patch works for now as a workaround, directly calling
> ifunc resolvers without following the ifunc ABI does not work. GDB only
> passes HWCAP as the first argument, so the resolver may return different
> functions due to the set of HWCAP values given not being identical between
> GDB and GLIBC (ie. It could call the wrong malloc implementation that was
> not selected or initialized).
> 
> So the best option is to call dlsym() as Florian suggested.

To track this, could either of you file a GDB bug with the necessary
background (why it would be good to switch to using to dlsym to resolve
ifuncs)?

Thanks,

Simon

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

[Muhammad Kamran]

Hi Simon,

On 03/07/2026 13:56, Simon Marchi wrote:
> On 6/30/26 11:29 AM, Wilco Dijkstra wrote:
>> Hi Muhammad,
>>
>>> Yes.  GDB should prefer the cache/GOT path and avoid resolver calls
>>> where possible.  The patch does not make resolver calls safer or add a
>>> new resolver-calling mechanism; it just preserves the IFUNC marker so
>>> the existing IFUNC resolution path is used instead of calling the
>>> resolver address as though it were malloc itself.
>>
>> Indeed - while the patch works for now as a workaround, directly calling
>> ifunc resolvers without following the ifunc ABI does not work. GDB only
>> passes HWCAP as the first argument, so the resolver may return different
>> functions due to the set of HWCAP values given not being identical between
>> GDB and GLIBC (ie. It could call the wrong malloc implementation that was
>> not selected or initialized).
>>
>> So the best option is to call dlsym() as Florian suggested.
> 
> To track this, could either of you file a GDB bug with the necessary
> background (why it would be good to switch to using to dlsym to resolve
> ifuncs)?

A GDB bug has been created on bugzilla and can be seen here:
https://sourceware.org/bugzilla/show_bug.cgi?id=34367

> 
> Thanks,
> 
> Simon