Re: [PATCH v8 1/8] nptl: fix potential merge of __rseq_* relro symbols

[Michael Jeanson <mjeanson@efficios.com>]

On 2024-02-15 21 h 02, DJ Delorie wrote:
> 
> Michael Jeanson <mjeanson@efficios.com> writes:
>> We tracked this to the use of '-fmerge-all-constants' which allows the
>> compiler to merge identical constant variables.
> 
> I assume the linker's constant (string?) merging won't affect this
> because the section is marked as writable to the linker?

I checked and the .data.rel.ro section does indeed have the SHF_WRITE 
flag set. My understanding is that the section would need to be 
read-only and the SHF_MERGE flag would need to be set for the linker to 
try merging things.


>> diff --git a/sysdeps/nptl/dl-tls_init_tp.c b/sysdeps/nptl/dl-tls_init_tp.c
>> index 092c274f36..80eb0107b5 100644
>> --- a/sysdeps/nptl/dl-tls_init_tp.c
>> +++ b/sysdeps/nptl/dl-tls_init_tp.c
>> @@ -45,8 +45,10 @@ rtld_mutex_dummy (pthread_mutex_t *lock)
>>   #endif
>>   
>>   const unsigned int __rseq_flags;
>> -const unsigned int __rseq_size attribute_relro;
>> -const ptrdiff_t __rseq_offset attribute_relro;
>> +
>> +/* The variables are in .data.relro but are not yet write-protected.  */
>> +extern unsigned int _rseq_size attribute_relro attribute_hidden;
>> +extern ptrdiff_t _rseq_offset attribute_relro attribute_hidden;
> 
> er, extern *and* hidden?  And relro?
> 
> In theory the relro one is harmless but meaningless, as externs don't
> have sections in the local compilation unit.
> 
> The hidden one will mark the symbol hidden, but does that really matter
> as long as it's marked hidden where it's defined?

Both attributes can be removed, the definition in the assembly file is 
what matters. I'll clean this in the next patch series.