PATCH: PR gold/14858: X32 TLS relocations are incorrectly handled

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

PATCH: PR gold/14858: X32 TLS relocations are incorrectly handled

H.J. Lu-30
Hi,

This patch properly handles LD to LE optimizaton for x32.  OK to
install for trunk and 2.23?

BTW, we can use

memcpy(view - 3, "\x66\x66\x66\x64\x48\x8b\x04\x25\0\0\0", 12);

instead of

memcpy(view - 3, "\x66\x66\x66\x64\x48\x8b\x04\x25\0\0\0\0", 12);

since there is a nul terminator at the end of string.  But my patch
leaves it alone.

Thanks.


H.J.
2012-11-19  H.J. Lu  <[hidden email]>

        PR gold/14858
        * x86_64.cc (Relocate::tls_ld_to_le): Support x32.

diff --git a/gold/x86_64.cc b/gold/x86_64.cc
index 6342196..fd3a202 100644
--- a/gold/x86_64.cc
+++ b/gold/x86_64.cc
@@ -3965,8 +3965,12 @@ Target_x86_64<size>::Relocate::tls_ld_to_le(
     section_size_type view_size)
 {
   // leaq foo@tlsld(%rip),%rdi; call __tls_get_addr@plt;
+  // For SIZE == 64:
   // ... leq foo@dtpoff(%rax),%reg
   // ==> .word 0x6666; .byte 0x66; movq %fs:0,%rax ... leaq x@tpoff(%rax),%rdx
+  // For SIZE == 32:
+  // ... leq foo@dtpoff(%rax),%reg
+  // ==> nopl 0x0(%rax); movq %fs:0,%eax ... leaq x@tpoff(%rax),%rdx
 
   tls::check_range(relinfo, relnum, rela.get_r_offset(), view_size, -3);
   tls::check_range(relinfo, relnum, rela.get_r_offset(), view_size, 9);
@@ -3976,7 +3980,10 @@ Target_x86_64<size>::Relocate::tls_ld_to_le(
 
   tls::check_tls(relinfo, relnum, rela.get_r_offset(), view[4] == 0xe8);
 
-  memcpy(view - 3, "\x66\x66\x66\x64\x48\x8b\x04\x25\0\0\0\0", 12);
+  if (size == 64)
+    memcpy(view - 3, "\x66\x66\x66\x64\x48\x8b\x04\x25\0\0\0\0", 12);
+  else
+    memcpy(view - 3, "\x0f\x1f\x40\x00\x64\x8b\x04\x25\0\0\0\0", 12);
 
   // The next reloc should be a PLT32 reloc against __tls_get_addr.
   // We can skip it.
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: PR gold/14858: X32 TLS relocations are incorrectly handled

Ian Lance Taylor
"H.J. Lu" <[hidden email]> writes:

> BTW, we can use
>
> memcpy(view - 3, "\x66\x66\x66\x64\x48\x8b\x04\x25\0\0\0", 12);
>
> instead of
>
> memcpy(view - 3, "\x66\x66\x66\x64\x48\x8b\x04\x25\0\0\0\0", 12);
>
> since there is a nul terminator at the end of string.  But my patch
> leaves it alone.

It doesn't matter, GCC should take care of it anyhow.


> 2012-11-19  H.J. Lu  <[hidden email]>
>
> PR gold/14858
> * x86_64.cc (Relocate::tls_ld_to_le): Support x32.

> +  // For SIZE == 64:
>    // ... leq foo@dtpoff(%rax),%reg
>    // ==> .word 0x6666; .byte 0x66; movq %fs:0,%rax ... leaq x@tpoff(%rax),%rdx
> +  // For SIZE == 32:
> +  // ... leq foo@dtpoff(%rax),%reg
> +  // ==> nopl 0x0(%rax); movq %fs:0,%eax ... leaq x@tpoff(%rax),%rdx

Do you mean movq %rax or do you mean movl %eax?  Please correct.

This is OK with that change.

Thanks.

Ian
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: PR gold/14858: X32 TLS relocations are incorrectly handled

H.J. Lu-30
On Mon, Nov 19, 2012 at 9:45 PM, Ian Lance Taylor <[hidden email]> wrote:

> "H.J. Lu" <[hidden email]> writes:
>
>> BTW, we can use
>>
>> memcpy(view - 3, "\x66\x66\x66\x64\x48\x8b\x04\x25\0\0\0", 12);
>>
>> instead of
>>
>> memcpy(view - 3, "\x66\x66\x66\x64\x48\x8b\x04\x25\0\0\0\0", 12);
>>
>> since there is a nul terminator at the end of string.  But my patch
>> leaves it alone.
>
> It doesn't matter, GCC should take care of it anyhow.
>
>
>> 2012-11-19  H.J. Lu  <[hidden email]>
>>
>>       PR gold/14858
>>       * x86_64.cc (Relocate::tls_ld_to_le): Support x32.
>
>> +  // For SIZE == 64:
>>    // ... leq foo@dtpoff(%rax),%reg
>>    // ==> .word 0x6666; .byte 0x66; movq %fs:0,%rax ... leaq x@tpoff(%rax),%rdx
>> +  // For SIZE == 32:
>> +  // ... leq foo@dtpoff(%rax),%reg
>> +  // ==> nopl 0x0(%rax); movq %fs:0,%eax ... leaq x@tpoff(%rax),%rdx
>
> Do you mean movq %rax or do you mean movl %eax?  Please correct.

I mean "movl %fs:0,%eax" since pointer is 32-bit in x32.

> This is OK with that change.
>

Checked into trunk and 2.23.

Thanks.


--
H.J.