Re: [PATCH 0/1] Revert "malloc: aarch64: Add ifuncs for malloc functions"

Hi Adhemerval,

>> I prepared this "revert" patch so that we can have it ready in case we
>> decide to revert it before the release. It would likely be permanent
>> since after the release we'd be in the same situation as we are now.
>>
>>> I'm leaning to the opinion that gdb and valgrind do the wrong thing, and while
>>> it's allright to give them more time to fix that, eventually the ifunc solution
>>> makes sense. Without a compatibility kludge, I mean, since it makes something
>>> complex even more complicated...
>>>
>>> More opinions welcome.
>>
>> I think we should keep malloc ifuncs in, and this will hopefully
>> create the pressure to fix these problems in GDB, Valgrind and other
>> tools that may be affected. However, I also understand that this
>> could be quite disruptive.

> I *think* valgrind works in this scenario, at least elf/tst-valgrind-smoke
> does not regress and the testcase calls malloc. And think valgrind does
> not issue anything similar to what gdb with the inferior memory allocation.

Yury showed Valgrind triggers with my check [1] - basically it allocates a 73MB mmap
using malloc. So that means it uses the address of the malloc ifunc as the start of its
private memory which could lead to odd failures that may be hard to debug.

So there are really 2 options for this release:

1. We revert the ifuncs.

2. We add my check [1] to the current malloc ifunc so buggy cases are detected and
   reported with a clear error.

In all cases we separately push for GDB and Valgrind fixes. However we do need to
have a clear story of whether we want to allow GLIBC ifunc resolvers to ever be called
from user code or not. Also we need to explain the correct way of calling a function -
eg. scan dynamic relocs and use the GOT entry it points to or use dlsym() if there is
no GOT entry or something else.

Cheers,
Wilco

[1] https://sourceware.org/pipermail/libc-alpha/2026-July/178497.html