Re: [PATCH 4/4] htl: move pthread_self into libc

[Guy-Fleury Iteriteka <gfleury@disroot.org>]

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

Thanks I will retry this ween'k end

On October 31, 2022 9:24:59 AM GMT+02:00, Florian Weimer <fw@deneb.enyo.de> wrote:
>* Guy-Fleury Iteriteka via Libc-alpha:
>
>> diff --git a/htl/Versions b/htl/Versions
>> index 1ef8a6d0..59070181 100644
>> --- a/htl/Versions
>> +++ b/htl/Versions
>> @@ -25,7 +25,9 @@ libc {
>>    GLIBC_2.32 {
>>      thrd_current; thrd_equal; thrd_sleep; thrd_yield;
>>    }
>> -
>> +  GLIBC_2.36 {
>> +    __pthread_self;
>> +  }
>
>This needs to be GLIBC_2.37 now.  I think it also needs to be
>pthread_self (the public symbol).
>
>> diff --git a/sysdeps/mach/hurd/i386/libc.abilist b/sysdeps/mach/hurd/i386/libc.abilist
>> index 26552958..bfa47282 100644
>> --- a/sysdeps/mach/hurd/i386/libc.abilist
>> +++ b/sysdeps/mach/hurd/i386/libc.abilist
>> @@ -29,6 +29,7 @@ GLIBC_2.11 mkostemps64 F
>>  GLIBC_2.11 mkstemps F
>>  GLIBC_2.11 mkstemps64 F
>>  GLIBC_2.12 pthread_equal F
>> +GLIBC_2.12 pthread_self F
>>  GLIBC_2.13 __fentry__ F
>>  GLIBC_2.14 syncfs F
>>  GLIBC_2.15 __fdelt_chk F
>
>“GLIBC_2.37 pthread_self” needs to show up there, in addition to the
>GLIBC_2.12 version.
>
>What's missing from this change is the construct for setting the
>symbol versions, something like:
>
>versioned_symbol (libc, __pthread_self, pthread_self, GLIBC_2_37);
>#if OTHER_SHLIB_COMPAT (librt, GLIBC_2_12, GLIBC_2_37)
>compat_symbol (libc, __pthread_self, pthread_self, GLIBC_2_12);
>#endif
>
>This sets the new symbol version explicitly and provides the old
>version as a compatibility symbol.
>
>It may be necessary to introduce a hidden prototype for
>__pthread_self, to avoid check-localplt warnings.  You may have to use
>libc_hidden_ver and a different name in the C function definition to
>work around some symbol management limitations.  Another approach
>could use an inline function for pthread_self or __pthread_self, so
>that glibc-internal use of the symbol goes away completely.
>
>Use of a __thread variable for ___pthread_self is problematic because
>it interferes with dlmopen.  If you use THREAD_GETMEM instead, I
>believe you can do away with the conditional check in pthread_self.