On Mon, Mar 5, 2012 at 6:03 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> X86-64 linker optimizes TLS_MODEL_INITIAL_EXEC to TLS_MODEL_LOCAL_EXEC
>>> by checking
>>>
>>> movq foo@gottpoff(%rip), %reg
>>>
>>> and
>>>
>>> addq foo@gottpoff(%rip), %reg
>>>
>>> It uses the REX prefix to avoid the last byte of the previous
>>> instruction. With 32bit Pmode, we may not have the REX prefix and
>>> the last byte of the previous instruction may be an offset, which
>>> may look like a REX prefix. IE->LE optimization will generate corrupted
>>> binary. This patch makes sure we always output an REX pfrefix for
>>> UNSPEC_GOTNTPOFF. OK for trunk?
>>
>> Actually, linker has:
>>
>> case R_X86_64_GOTTPOFF:
>> /* Check transition from IE access model:
>> mov foo@gottpoff(%rip), %reg
>> add foo@gottpoff(%rip), %reg
>> */
>>
>> /* Check REX prefix first. */
>> if (offset >= 3 && (offset + 4) <= sec->size)
>> {
>> val = bfd_get_8 (abfd, contents + offset - 3);
>> if (val != 0x48 && val != 0x4c)
>> {
>> /* X32 may have 0x44 REX prefix or no REX prefix. */
>> if (ABI_64_P (abfd))
>> return FALSE;
>> }
>> }
>> else
>> {
>> /* X32 may not have any REX prefix. */
>> if (ABI_64_P (abfd))
>> return FALSE;
>> if (offset < 2 || (offset + 3) > sec->size)
>> return FALSE;
>> }
>>
>> So, it should handle the case without REX just OK. If it doesn't, then
>> this is a bug in binutils.
>>
>
> The last byte of the displacement in the previous instruction
> may happen to look like a REX byte. In that case, linker
> will overwrite the last byte of the previous instruction and
> generate the wrong instruction sequence.
>
> I need to update linker to enforce the REX byte check.
One important observation: if we want to follow the x86_64 TLS spec
strictly, we have to use existing DImode patterns only. This also
means that we should NOT convert other TLS patterns to Pmode, since
they explicitly state movq and addq. If this is not the case, then we
need new TLS specification for X32.
Uros.
>
> --
> H.J.
