[PATCH] i386: Change offset of __private_ss to 0x30

[H.J. Lu]

On Mon, Jun 4, 2018 at 6:43 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Jun 4, 2018 at 6:30 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 05/30/2018 06:47 PM, H.J. Lu wrote:
>>>
>>> On Wed, May 30, 2018 at 9:43 AM, Florian Weimer <fweimer@redhat.com>
>>> wrote:
>>>>
>>>> On 05/30/2018 04:49 PM, H.J. Lu wrote:
>>>>>
>>>>>
>>>>> diff --git a/sysdeps/i386/nptl/tls.h b/sysdeps/i386/nptl/tls.h
>>>>> index 6c36e58e9c..afb71ce431 100644
>>>>> --- a/sysdeps/i386/nptl/tls.h
>>>>> +++ b/sysdeps/i386/nptl/tls.h
>>>>> @@ -43,11 +43,16 @@ typedef struct
>>>>>      int gscope_flag;
>>>>>      int __glibc_reserved1;
>>>>>      /* Reservation of some values for the TM ABI.  */
>>>>> -  void *__private_tm[4];
>>>>> +  void *__private_tm[3];
>>>>>      /* GCC split stack support.  */
>>>>>      void *__private_ss;
>>>>> +  void *__glibc_reserved2;
>>>>>    } tcbhead_t;
>>>>
>>>>
>>>>
>>>> What's the state of TM in GCC?  Has it already been removed?
>>>
>>>
>>> libitm has its own issue:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85988
>>>
>>> Fortunately, only the first 2 elements in __private_tm are used by
>>> libitm.
>>
>>
>> Looks like the reuse of the TM fields was actually deliberate:
>
> True.
>
>>   <https://sourceware.org/bugzilla/show_bug.cgi?id=10686>
>>
>> But the offsets are still wrong.
>
> Yes, we are stuck with the wrong offset.
>
>> The question still remains whether we still need libitm.
>>
>
> libitm is enabled by default in GCC.
>

I am checking in my patch:

https://sourceware.org/ml/libc-alpha/2018-05/msg00883.html

today to match what libgcc uses.

-- 
H.J.