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

[H.J. Lu]

On Fri, Jul 3, 2026 at 9:53 PM Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
>
> 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 -

I have been calling IFUNC functions, like strcmp, in GDB for a long time.
There is no issue, other than GDB can't figure out its return type.  I
have to cast
the return value to int:

(gdb) cond 1 (int) strcmp (name, "foo") == 0

> 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



-- 
H.J.