[Bug ld/20868] New: ld relaxes TLS access erroneously for aarch64 in ilp32 mode

[ynorov at caviumnetworks dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20868

            Bug ID: 20868
           Summary: ld relaxes TLS access erroneously for aarch64 in ilp32
                    mode
           Product: binutils
           Version: 2.24
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: ynorov at caviumnetworks dot com
  Target Milestone: ---

Created attachment 9669
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9669&action=edit
test to reproduce the bug

ld -v:
GNU ld (Cavium Inc. Version 0.99 build 428) 2.24.51.20140823

asm volatile() snippet:
        register unsigned long __result asm ("w0");
        asm volatile ("adrp %0, :tlsgd:foo; \n"
                        "add %w0, %w0, #:tlsgd_lo12:foo; \n"
                        "bl my_tls_get_addr;\n"
                        "nop\n"
                        : "=r" (__result)
                        :
                        : "x1", "x2", "x3", "x4", "x5", "x6", "x7",
                        "x8", "x9", "x10", "x11", "x12", "x13",
                        "x14", "x15", "x16", "x17", "x18", "x30",
                        "memory", "cc");
        bp = (unsigned int *) __result;

The code above generates next assembly in object file: 
        register unsigned long __result asm ("w0");
        asm volatile ("adrp %0, :tlsgd:foo; \n"
  c8:   90000000        adrp    x0, 4 <my_tls_get_addr+0x4>
  cc:   11000000        add     w0, w0, #0x0
  d0:   94000000        bl      0 <my_tls_get_addr>
  d4:   d503201f        nop
                        :
                        : "x1", "x2", "x3", "x4", "x5", "x6", "x7",
                        "x8", "x9", "x10", "x11", "x12", "x13",
                        "x14", "x15", "x16", "x17", "x18", "x30",
                        "memory", "cc");
        bp = (unsigned int *) __result;
  d8:   2a0003e7        mov     w7, w0
  dc:   b9001ba7        str     w7, [x29,#24]

But in executalbe binary ld relaxes tls access with direct address calculation:
279         register unsigned long __result asm ("w0");
280         asm volatile ("adrp %0, :tlsgd:foo; \n"
281   400618:       90000080        adrp    x0, 410000 <__FRAME_END__+0xf828>
282   40061c:       f948ec00        ldr     x0, [x0,#4568]
283   400620:       d53bd041        mrs     x1, tpidr_el0
284   400624:       8b000020        add     x0, x1, x0
285                         :
286                         : "x1", "x2", "x3", "x4", "x5", "x6", "x7",
287                         "x8", "x9", "x10", "x11", "x12", "x13",
288                         "x14", "x15", "x16", "x17", "x18", "x30",
289                         "memory", "cc");
290         bp = (unsigned int *) __result;
291   400628:       2a0003e7        mov     w7, w0
292   40062c:       b9001ba7        str     w7, [x29,#24]

So ld detects the access to tls that it can optimize, but does it wrong -
actual address is less that expected by 8. In lp64 mode ld does the same, but
the result is correct.

Full test source is attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.