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

[Yury Khrustalev]

On Wed, Jul 01, 2026 at 12:25:59PM -0300, Adhemerval Zanella Netto wrote:
> >
> > ...
> > 
> > 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.
> 
> But for ifunc resolver entered with ambiguous register state, we cannot satisfy
> both:
> 
> * Caller wants the resolver to behave like the function call (i.e - malloc 
>   do the allocation).

I don't think we should even discuss this.

> * Caller wants the resolver to return the resolved address.

If caller wants something else from an ifunc resolver, it is an error
and we should abort.

> 
> The on-entry state doesn't reliably encode intent across targets and ABI 
> versions. On aarch64 you could test arg1 & _IFUNC_ARG_HWCAP, but:
> 
> 1. that only separates new-ABI resolver call from everything else, it doesn't 
>    rescue legacy case-2 callers (or any other ifunc that uses more 2 argument).

Yep, as Wilco suggested we can use

  (arg0 & ~_IFUNC_ARG_HWCAP) == GLRO (dl_hwcap)

> 
> 2. there's no in-band way to validate that a passed HWCAP is correct 
>    (garbage HWCAP just silently selects some implementation).
> 
> That's why I think we should decouple both target.