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

  Introduce ifuncs and resolvers for functions pertinent to the
malloc interface on the AArch64 target: malloc, calloc, free,
realloc, memalign, valloc, pvalloc, posix_memalign, aligned_alloc,
free_sized, free_aligned_sized, malloc_usable_size.

A target can define the USE_MULTIARCH_MALLOC macro. In this case
it must provide alternative aliases for the malloc functions that
point to the ifuncs.

This implementation respects the --disable-multi-arch configure
flag. If multi-arch support is disabled, the generic aliases
are used on aarch64.

This patch contains aarch64-specific resolvers. At this point they
return core implementations but in the future they can be changed
to support for features, e.g. to handle memory tagging.
---
 malloc/malloc-internal.h                  |  1 +
 malloc/malloc.c                           | 11 ++-
 sysdeps/aarch64/multiarch/Makefile        |  6 ++
 sysdeps/aarch64/multiarch/malloc-ifuncs.c | 82 +++++++++++++++++++++++
 sysdeps/aarch64/multiarch/malloc-ifuncs.h | 25 +++++++
 sysdeps/generic/malloc-ifuncs.h           | 36 ++++++++++
 6 files changed, 159 insertions(+), 2 deletions(-)
 create mode 100644 sysdeps/aarch64/multiarch/malloc-ifuncs.c
 create mode 100644 sysdeps/aarch64/multiarch/malloc-ifuncs.h
 create mode 100644 sysdeps/generic/malloc-ifuncs.h
  

On Tue, Jul 28, 2026 at 05:12:15PM +0100, Yury Khrustalev wrote:
> Introduce ifuncs and resolvers for functions pertinent to the
> malloc interface on the AArch64 target: malloc, calloc, free,
> realloc, memalign, valloc, pvalloc, posix_memalign, aligned_alloc,
> free_sized, free_aligned_sized, malloc_usable_size.
> 
> A target can define the USE_MULTIARCH_MALLOC macro. In this case
> it must provide alternative aliases for the malloc functions that
> point to the ifuncs.
> 
> This implementation respects the --disable-multi-arch configure
> flag. If multi-arch support is disabled, the generic aliases
> are used on aarch64.
> 
> This patch contains aarch64-specific resolvers. At this point they
> return core implementations but in the future they can be changed
> to support for features, e.g. to handle memory tagging.
> ---
>  malloc/malloc-internal.h                  |  1 +
>  malloc/malloc.c                           | 11 ++-
>  sysdeps/aarch64/multiarch/Makefile        |  6 ++
>  sysdeps/aarch64/multiarch/malloc-ifuncs.c | 82 +++++++++++++++++++++++
>  sysdeps/aarch64/multiarch/malloc-ifuncs.h | 25 +++++++
>  sysdeps/generic/malloc-ifuncs.h           | 36 ++++++++++
>  6 files changed, 159 insertions(+), 2 deletions(-)
>  create mode 100644 sysdeps/aarch64/multiarch/malloc-ifuncs.c
>  create mode 100644 sysdeps/aarch64/multiarch/malloc-ifuncs.h
>  create mode 100644 sysdeps/generic/malloc-ifuncs.h

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.

[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=34330
[2]: https://inbox.sourceware.org/gdb-patches/20260630110443.12900-1-muhammad.kamran@arm.com/

Thanks,
Yury
  

On 29/07/26 10:21, Yury Khrustalev wrote:
> On Tue, Jul 28, 2026 at 05:12:15PM +0100, Yury Khrustalev wrote:
>> Introduce ifuncs and resolvers for functions pertinent to the
>> malloc interface on the AArch64 target: malloc, calloc, free,
>> realloc, memalign, valloc, pvalloc, posix_memalign, aligned_alloc,
>> free_sized, free_aligned_sized, malloc_usable_size.
>>
>> A target can define the USE_MULTIARCH_MALLOC macro. In this case
>> it must provide alternative aliases for the malloc functions that
>> point to the ifuncs.
>>
>> This implementation respects the --disable-multi-arch configure
>> flag. If multi-arch support is disabled, the generic aliases
>> are used on aarch64.
>>
>> This patch contains aarch64-specific resolvers. At this point they
>> return core implementations but in the future they can be changed
>> to support for features, e.g. to handle memory tagging.
>> ---
>>  malloc/malloc-internal.h                  |  1 +
>>  malloc/malloc.c                           | 11 ++-
>>  sysdeps/aarch64/multiarch/Makefile        |  6 ++
>>  sysdeps/aarch64/multiarch/malloc-ifuncs.c | 82 +++++++++++++++++++++++
>>  sysdeps/aarch64/multiarch/malloc-ifuncs.h | 25 +++++++
>>  sysdeps/generic/malloc-ifuncs.h           | 36 ++++++++++
>>  6 files changed, 159 insertions(+), 2 deletions(-)
>>  create mode 100644 sysdeps/aarch64/multiarch/malloc-ifuncs.c
>>  create mode 100644 sysdeps/aarch64/multiarch/malloc-ifuncs.h
>>  create mode 100644 sysdeps/generic/malloc-ifuncs.h
> 
> 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)?

> 
> [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=34330
> [2]: https://inbox.sourceware.org/gdb-patches/20260630110443.12900-1-muhammad.kamran@arm.com/
> 
> Thanks,
> Yury
>
  

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/20260625152036.6149-1-muhammad.kamran@arm.com/

Thanks,
Yury
  

Hi Yury,

> 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 2) there isn't really a good and easy solution...


I'm surprised that it's 2026 and debuggers haven't figured out how not to corrupt
the program they are debugging...

Multiple good solutions have been proposed. Firstly, don't ever implicitly call
malloc() to avoid corrupting user state. By default place strings on the stack and
tell users to use strdup ("string") in the rare case where they want a pointer with
infinite lifetime. This makes it explicit there is an allocation that will affect user
state. One could autoinsert the strdup around strings if a particular setting is enabled.

As mentioned before, GLIBC could provide a special entry point for allocating
small amounts of memory by GDB that doesn't interfere with malloc(). It would
be a reasonable solution for GLIBC, but not all libc's might support it.

Cheers,
Wilco
  

* Wilco Dijkstra:

> Hi Yury,
>
>> 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 2) there isn't really a good and easy solution...
>
>
> I'm surprised that it's 2026 and debuggers haven't figured out how not
> to corrupt the program they are debugging...

It's hardly suprising because Linux does not provide a way to make a
system call using the ptrace interface.  I'm pretty sure debuggers
wouldn't bother with calling malloc if they just could make a mmap
system call in the target process to allocate some memory.

Thanks,
Florian
  

On Jul 31 2026, Wilco Dijkstra wrote:

> state. One could autoinsert the strdup around strings if a particular setting is enabled.

How is strdup different from malloc?
  

Hi Andreas,

>> state. One could autoinsert the strdup around strings if a particular setting is enabled.
>
> How is strdup different from malloc?

In that it is both optional and explicit user choice, unlike the malloc
call which can't even be switched off (if it could, the issue with ifuncs
wouldn't be that serious).

Cheers,
Wilco
  

On Jul 31 2026, Wilco Dijkstra wrote:

> Hi Andreas,
>
>>> state. One could autoinsert the strdup around strings if a particular setting is enabled.
>>
>> How is strdup different from malloc?
>
> In that it is both optional and explicit user choice, unlike the malloc

Nothing of that makes it is really different.

> call which can't even be switched off (if it could, the issue with ifuncs
> wouldn't be that serious).

The static allocation is required for proper semantics.