On 23/06/2026 04:00, Thiago Jung Bauermann wrote:

Hello Yury,

Yury Khrustalev Yury.Khrustalev@arm.com writes:

...

Hi, thanks for this report.

I've looked into these issues, and it seems like most of them are caused by how GDB treats malloc function for evaluating expressions that require a function call.

GDB seems to ignore that malloc has become n ifunc in Glibc and it tries to access symbol 'malloc' directly.

It seems like GDB has been having some issues with ifuncs before, e.g. [1].

Simple way to reproduce the issue: use a program with just empty main function:

int main(void) { return 0; }

In GDB (not that __libc_malloc is the implementation that is returned by the ifunc resolver):

(gdb) br main (gdb) r (gdb) disassemble __libc_malloc

Notice first 2 instructions

(gdb) call printf("%s\n", "hello")

Might result in SIGILL or SIGSEGV... but if it works, it prints format string instead of 'hello'.

(gdb) disassemble __libc_malloc

Notice first 2 instructions have now been re-written with gibberish (hence the signals).

I would appreciate if this could be looked at from the GDB point of view. Perhaps, this should be fixed in GDB?

FWIW, lldb works as expected.

Thank you for the investigation and the detailed report. I was able to reproduce the problem and will work on a fix.

Hi Thiago,

I’ve spent some time looking into this issue. The problem appears to be in find_function_in_inferior, which GDB uses when expression evaluation needs to call functions in the inferior, such as malloc for allocating storage for string literal arguments.

When the lookup falls back to a minimal symbol, GDB constructs a synthetic function type from the symbol address. For GNU IFUNC symbols such as malloc, this path loses the IFUNC marker, causing the inferior call machinery to treat the symbol as an ordinary function and skip IFUNC resolution.

The patch below preserves the IFUNC property when creating the synthetic function type. With this change, Yury’s reproducer behaves correctly on my setup.

Does this look like a reasonable approach to you?

Thanks, Kamran

-- >8 -- commit 960287b93f737dab13d7be40612dcc091b69737d Author: Muhammad Kamran muhammad.kamran@arm.com Date: Mon Jun 22 16:55:23 2026 +0100

gdb: Preserve IFUNC marker when finding inferior functions

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.

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;