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

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