On 23/06/2026 04:00, Thiago Jung Bauermann wrote:
Hello Yury,
Yury Khrustalev <[email protected]> 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 <[email protected]>
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;
_______________________________________________
linaro-toolchain mailing list -- [email protected]
To unsubscribe send an email to [email protected]
