[committed] hppa: undef __ASSUME_SET_ROBUST_LIST

[Florian Weimer]

* Adhemerval Zanella Netto:

> On 21/09/22 09:49, Florian Weimer wrote:
>> * Adhemerval Zanella Netto via Libc-alpha:
>> 
>>> On 20/09/22 17:20, John David Anglin wrote:
>>>> QEMU does not support support set_robust_list. Thus, we need
>>>> to enable detection of set_robust_list system call.
>>>>
>>>> Signed-off-by: John David Anglin <dave.anglin@bell.net>
>>>> ---
>>>> diff --git a/sysdeps/unix/sysv/linux/hppa/kernel-features.h b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>>>> index 0cd21ef0fa..079612e4aa 100644
>>>> --- a/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>>>> +++ b/sysdeps/unix/sysv/linux/hppa/kernel-features.h
>>>> @@ -30,3 +30,6 @@
>>>>  
>>>>  #undef __ASSUME_CLONE_DEFAULT
>>>>  #define __ASSUME_CLONE_BACKWARDS 1
>>>> +
>>>> +/* QEMU does not support set_robust_list.  */
>>>> +#undef __ASSUME_SET_ROBUST_LIST
>>>>
>>>
>>> Does it happen only for hppa? If is a generic missing feature maybe we should
>>> undef __ASSUME_SET_ROBUST_LIST for all architectures.
>> 
>> I think it's just a 32-bit/64-bit mismatch issue.  You can't create
>> 32-bit robust futexes from a 64-bit process because the pointer size in
>> the robust list differs.  For non-process-shared mutexes, qemu-user
>> should be able to emulate these futexes in userspace.  It already has to
>> intercept thread exit, and it can walk the mutex list at that time.
>> 
>> I don't think it makes sense to pessimize bare-metal uses simply because
>> there's a qemu-user limitation.
>
> Should we revert the hppa fix then? 

Probably?  It seems to be an emulation-only problem.

Thanks,
Florian