[PATCH v7 20/23] aarch64: Process gnu properties in static exe

[Adhemerval Zanella Netto]

On 10/01/25 07:30, Yury Khrustalev wrote:
> On Thu, Jan 09, 2025 at 03:01:37PM -0300, Adhemerval Zanella Netto wrote:
>>
>>
>> On 03/01/25 12:41, Yury Khrustalev wrote:
>>> From: Szabolcs Nagy <szabolcs.nagy@arm.com>
>>>
>>> Unlike for BTI, the kernel does not process GCS properties so update
>>> GL(dl_aarch64_gcs) before the GCS status is set.
>>>
>>> Co-authored-by: Yury Khrustalev <yury.khrustalev@arm.com>
>>> ---
>>>  csu/libc-start.c                             | 12 ++++++++++++
>>>  sysdeps/generic/libc-start.h                 |  1 +
>>>  sysdeps/unix/sysv/linux/aarch64/libc-start.h | 19 +++++++++++++++++++
>>>  3 files changed, 32 insertions(+)
>>>
>>> diff --git a/csu/libc-start.c b/csu/libc-start.c
>>> index 6f3d52e223..325ef010d4 100644
>>> --- a/csu/libc-start.c
>>> +++ b/csu/libc-start.c
>>> @@ -206,6 +206,10 @@ call_fini (void *unused)
>>>  
>>>  #include <libc-start.h>
>>>  
>>> +#ifndef ARCH_PROCESS_NOTES
>>> +# define ARCH_PROCESS_NOTES()
>>> +#endif
>>> +
>>
>> I think it would be better to avoid the old way of defining arch-hooks,
>> since they are error-prone.  For instance, although is not the case
>> (since the function is currently empty) if/when we need to add generic
>> __libc_process_notes code, just adding on the function below will not 
>> be suffice for x86_64/powerpc because they have its own libc-start.h 
>> (and this patch did not add an ARCH_PROCESS_NOTES for such ABIs).
>>
>> Instead, the usual way is to either use the generic definitions
>> on sysdeps/generic or add a new one.  For this case, I think it would
>> be better to add new a file with the notes processing function instead
>> of reuse the dl-prop.h.  
>>
>> I plan to use it to add the generic memory seal support, which requires 
>> PT_GNU_PROPERTY for all ABIs, without the need to replicate the same 
>> code on x86_64 (in fact, I can move the aarch64 definitions on generic 
>> code and remove aarch64 libc-prop.h).
> 
> In the interest of time, would it be OK if I revert this patch to its
> original version [1] so that we could make property processing generic
> later (as this is not require for GCS and would delay merging of this
> patch series)?
> 
> [1] https://inbox.sourceware.org/libc-alpha/20241129163721.2385847-20-yury.khrustalev@arm.com/
> 

Alright, sounds fair.