[PATCH 2/2] aarch64: Add workaround for GDB bug handling string literals

[Yury Khrustalev]

On Wed, Jul 01, 2026 at 10:25:59AM -0300, Adhemerval Zanella Netto wrote:
> 
> On 01/07/26 05:39, Yury Khrustalev wrote:
> > On Tue, Jun 30, 2026 at 01:15:04PM -0300, Adhemerval Zanella Netto wrote:
> >>
> >> On 30/06/26 12:29, Yury Khrustalev wrote:
> >>> On Tue, Jun 30, 2026 at 12:17:37PM -0300, Adhemerval Zanella Netto wrote:
> >>>>
> >>>> On 30/06/26 11:15, Wilco Dijkstra wrote:
> >>>>> Hi,
> >>>>>
> >>>>>> I don't like it either, but I don't see a better alternative to keep some
> >>>>>> compatibility with old gdb.
> >>>>>>
> >>>>>> But I also think this approach is fragile: it require some assumptions on how
> >>>>>> gdb implements this and adds some magic number.� I think a better alternative
> >>>>>> is invert the assumption: the only exactly legitimate caller of an IFUNC
> >>>>>> resolver is the the dynamic loader's relocation machinery
> >>>>>> (elf_ifunc_invoke / _dl_fixup):
> >>>>>
> >>>>> On AArch64 we can just check for !(arg0 & IFUNC_ARG_HWCAP) since we always
> >>>>> invoke ifuncs with that bit set from GLIBC (obviously the value is way too large to
> >>>>> ever be a valid allocation). You could also check arg0 == GLRO (dl_hwcap) for other
> >>>>> targets.
> >>>
> >>> Yes, we should do this, I'll make a patch.
> >>
> >> I think if we want to add this workaround, doing in a platform neutral is better
> >> than adding arch-specific knobs.
> > 
> > You probably missed second part of my reply. The idea is not to provide
> > a work-around for the problem in GDB. The idea is to fail early with a
> > clear error message when resolver is called incorrectly.
> > 
> > The patch series at the start of this thread *is* "arch-specific knobs".
> 
> I got that and my suggestion is doing exactly what you suggested [1],
> but in the generic way (enforce all ifunc alls originate inside ld.so, 
> so __builtin_return_address(0) lies within _dl_rtld_map's [l_map_start, l
> _map_end).

OK, I see. Well, resolvers should be as simple as possible, so I'd
rather do the check in the arch-specific way if it makes it smaller.

However, a resolver can be correctly called from other places. For
example, many binary instrumentation frameworks substitute dynamic
loader and try to implement everything that a usual dynamic loader
would do. With Wilco's approach, these use cases will work provided
that the arguments for the resolver are compliant with the ABI, but
a check based on the return address will fail rendering many valid
use cases incorrect.

> This will allow other ABIs to enable malloc ifunc without the need to come
> up with arch-specific heuristics.
> 
> And I think we should *decouple* the 1. stop the corruption goal from 2. 
> make GDB's string-literal path work.
> 
> [1] https://sourceware.org/pipermail/libc-alpha/2026-July/178497.html

Well, it's not just GDB, Valgrind does it as well:
https://bugs.kde.org/show_bug.cgi?id=522497

Thanks,
Yury