[Bug gdb/34367] GDB internal inferior malloc lookup may call GNU IFUNC resolver directly

https://sourceware.org/bugzilla/show_bug.cgi?id=34367

--- Comment #2 from Muhammad Kamran <muhammad.kamran at arm dot com> ---
The challenge with switching inferior allocation path from malloc to
mmap-backed allocation is that mmap is not a generic inferior capability in the
same way that calling a visible malloc symbol often is.

The current value_allocate_space_in_inferior path relies on GDB to find and
call an inferior malloc function. In contrast, an mmap-based allocator needs
target/OS/ABI-specific support. Some targets may have a C library malloc but no
mmap-like capability at all, e.g. bare-metal/newlib where malloc is backed by
sbrk or a fixed heap. Other targets may have an OS mapping primitive, but not
one exposed as a POSIX mmap/mmap64 function that GDB can safely call.

Using dlsym still seems like a reasonable approach for IFUNC symbol resolution
on dynamic ELF targets where dlsym is available.

Separately, Yury suggested a couple of smaller steps that could improve the
current situation around malloc IFUNCs:

1. GDB could validate that a symbol it is about to call from the inferior is
actually a normal callable function, not an IFUNC resolver. If GDB cannot
safely call it as a normal function, it should fail explicitly with a clear
diagnostic, similar to the current error when a static binary does not provide
malloc. That would at least avoid silent or misleading failures.

2. If dlsym, stack storage, or mmap-backed scratch storage are not available,
and GDB must use an inferior malloc-like function, GDB could provide a setting
for the function name to use. For example, a user debugging a glibc program
could configure GDB to call __libc_malloc rather than malloc.

I would be interested in feedback on whether these mitigations make sense, or
whether there is a better direction for handling the malloc IFUNC case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.