[PATCH][AArch64] Improve copy relocation support on four absolute relocation types

[Jiong Wang]

aarch64 static linker fail linking unreasonably when trying to link executable from .o
written by handle assembly which contain access of global symbol and generated without -fPIC.

/usr/bin/ld: x.o(.text+0x8): unresolvable R_AARCH64_MOVW_UABS_G0_NC relocation against...
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

I found the problem is caused by our incomplete support for calculating address of
global symbol by absolute relocation.

currently, if we calculating address by 32/64 bit absolute relocation, it's OK.

for example:

x.s
         
.8byte global_a
         
for .o, a ABS64 relocation created.

Relocation section '*.rela.text*' at offset 0x360 contains 1 entries:

R_AARCH64_ABS64        0000000000000000 global_a + 0
  
then if we:

   link into executable
   ============================
   copy relocation generated, and the original address in text section
   will point to .dynbss which this copy relocation will happen.

   *readelf -r x.exe*

   Relocation section '*.rela.dyn*' at offset 0x460 contains 9 entries:

     R_AARCH64_COPY         0000000000410830 stdout + 0

   link into shared library
   ========================
   R_AARCH64_ABS64 will be propagated to dynamic relocation section to let the
   runtime linker relocate on the text section directly.

   *readelf -r x.so*

   Relocation section '*.rela.dyn*' at offset 0x460 contains 9 entries:

     R_AARCH64_ABS64        0000000000000000 stdout + 0
   
while there is another way to form 64 bit address for global symbol by using
   
   movz x0,:abs_g0_nc:global_a (BFD_RELOC_AARCH64_MOVW_G0_NC)
   movk x0,:abs_g1_nc:global_a (BFD_RELOC_AARCH64_MOVW_G1_NC)
   movk x0,:abs_g2_nc:global_a (BFD_RELOC_AARCH64_MOVW_G2_NC)
   movk x0,:abs_g3:global_a    (BFD_RELOC_AARCH64_MOVW_G3)

to form the address from pieces instead of one single R_AARCH64_ABS64.

so for the above four relocation types, we need to support all those logic
AARCH64_ABS64 supported except when linking shared library to prevent
copy on write penalty.

  * for executable linking, generate copy relocation.
  * reject them when linking shared library.

this is also the approach arm32 adopted.

ok for trunk?

thanks.

-- Jiong

   bfd/
     * elfnn-aarch64.c (elfNN_aarch64_check_relocs): Initialize non_got_ref
     properly for MOVW_G0/1/2_NC and MOVW_G3. Reject them when linking
     shared library.
     (elfNN_aarch64_gc_sweep_hook): Add check on these relocs.

   ld/testsuite/
     * ld-aarch64/copy-relocs-so.s: New test file.
     * ld-aarch64/copy-relocs-exe.s: Likewise.
     * ld-aarch64/copy-relocs.d: New expectation file.
     * ld-aarch64/emit-relocs-264-bad.d: New test file.
     * ld-aarch64/emit-relocs-266-bad.d: Likewise.
     * ld-aarch64/emit-relocs-268-bad.d: Likewise.
     * ld-aarch64/emit-relocs-269-bad.d: Likewise.
     * ld-aarch64/aarch64-elf.exp: Run new added test.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-copy-reloc.patch
Type: text/x-patch
Size: 5922 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20140813/eb5b304e/attachment.bin>