On 27/05/2020 22:36, Vineet Gupta wrote:
> On 5/27/20 12:17 PM, Adhemerval Zanella via Libc-alpha wrote:
>>
>>
>> On 22/04/2020 22:41, Vineet Gupta via Libc-alpha wrote:
>>> This includes all 4 TLS addressing models
>>>
>>> Signed-off-by: Vineet Gupta <vgupta@xxxxxxxxxxxx>
>>
>> As prior patch we do not use DCO, but rather copyright assignment.
>>
>> Looks ok in general, with some comments below.
>
>>> +
>>> +register struct pthread *__thread_self __asm__("r25");
>>
>> This is used on other ports, but I am not sure if this is a valid definition
>> for a global variable.
>
> Not valid from gcc implementation POV ? The syntax seems to work alright in ARC
> linux kernel where we use r25 to cache the current task pointer.
The gcc documentation [1] does specify register global variables, but it
also states that
"[...] it is recommended that you choose a register that is normally saved and
restored by function calls on your machine, so that calls to library routines
will not clobber it."
So I see that the semantic of global register is kind fragile and since
it is usage is solely for asm inline argument I don't see a very compelling
reason to keep using it.
[1] https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html
>
>> Usually the register specifier is used as an input
>> for inline assembly. Do we really need this global on ARC port? Couldn't
>> we replace it with __builtin_thread_pointer where applicable?
>
> We do use __builtin_thread_pointer and actually __thread_self is not used in ARC
> port :-) so I can just drop it
Ack.
>
> Many thx for reviewing.
> -Vineet
>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
