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

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Fri Jul 3 13:12:03 GMT 2026



On 03/07/26 05:12, Yury Khrustalev wrote:
> Hi Andreas,
> 
> On Fri, Jul 03, 2026 at 11:31:40AM +0900, Andreas K. Huettel wrote:
>> Hi Yury, 
>>
>> what is your plan here? Do you want to revert it for the release (fine with me)
>> or permanently?
> 
> 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.

> 
> The GDB fix proves to be more complicated than we thought. As often,
> a proper fix means a bit of refactoring in GDB. There are mitigation
> options on the GDB side as well.
> 
> I don't think we should go ahead with the compatibility kludge patch
> since it doesn't cover all the use cases anyway.
> 
> I hope we can make a decision on this next Monday during the patch
> review call.
> 
> Kind regards,
> Yury
> 



More information about the Libc-alpha mailing list