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

[Adhemerval Zanella Netto]

On 01/07/26 12:53, Yury Khrustalev wrote:
> 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)
It still has a hole, any resolver(n) where (n~_IFUNC_ARG_HWCAP) == dl_hwcap
passes the check.  It might not a problem for malloc, but maybe for 
environments that manipulate hwcap (valgrind, etc.) that calls other ifunc 
besides malloc we might hit it eventually.

Maybe the arg0 maybe be added as a complementary arch-specific check after
the _dl_rtld_map bounds check.  The bound check still has the advantage of 
being platform-neutral and generic enough to not require any extra arch 
handling if some maintainer wants to enable malloc ifunc.