Re: [PATCH 2/2] malloc: aarch64: Add ifuncs for malloc functions

On Wed, Jul 29, 2026 at 03:59:32PM -0300, Adhemerval Zanella Netto wrote:
> 
> On 29/07/26 10:21, Yury Khrustalev wrote:
> > On Tue, Jul 28, 2026 at 05:12:15PM +0100, Yury Khrustalev wrote:
> > 
> > ...
> >
> > To work around this bug in GDB [1], it is possible to apply this GDB
> > patch from Muhammad [2]. It cleanly applies to GDB master as of now and
> > provides a fix that resolves the issue with malloc being ifunc.
> > 
> > Although, [2] is not a final fix, it resolves the immediate problem and
> > is stable (passes regression). This might be useful after malloc ifuncs
> > are merged to Glibc master and before GDB is fixed.
> 
> The change looks ok and I think it would be good to have it at the start of
> the development to have a lot of time for testing.
> 
> And what is missing from [2] to be considered a final fix? Are Muhammad aimed
> to change how gdb allocates process memory to make the function call (like
> using mmap or something else like stack allocation to avoid interfere with
> malloc metadata)?

There was a discussion under v2 of Muhammad's patch [1] and we are still
waiting for feedback on v4.

There are several things:

1) When GDB calls an ifunc resolver, it would likely not call it
correctly (i.e. passing both arguments with all the hwcaps and bits
set), so GDB could obtain ifunc implementation that is different from
what the program-under-debug would use.

2) General concern over using program's malloc that will inevitably
change the state of malloc implementation. E.g. what if we are debugging
malloc implementation itself and GDB is changing chunks behind the
scenes?

For 1) it was proposed to use dlsym() which will find correct
implementation of the ifunc however it requires a bit of work (e.g.
allocate memory for dlsym's argument on stack) and not all targets
support dlsym etc. There is work in progress patch for this I think.

For 2) there isn't really a good and easy solution...

[1]: https://inbox.sourceware.org/gdb-patches/[email protected]/

Thanks,
Yury