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

[Adhemerval Zanella Netto]

On 01/07/26 10:56, Yury Khrustalev wrote:
> 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.

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).

* Caller wants the resolver to return the resolved address.

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).

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.

> 
>> 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
>