Re: [PATCH 0/1] Revert "malloc: aarch64: Add ifuncs for malloc functions"
Adhemerval Zanella Netto <[email protected]>
| Newsgroups | gmane.comp.lib.glibc.alpha |
|---|---|
| Organization | Linaro |
| Message-ID | <[email protected]> |
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 >