[all-commits] [llvm/llvm-project] 894f74: [MIPS][ELF] Use PC-relative relocations in .eh_fra...

[Alexander Richardson via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 894f742acb977a09285dcab024e50c2cf6bce578
      https://github.com/llvm/llvm-project/commit/894f742acb977a09285dcab024e50c2cf6bce578
  Author: Alex Richardson <Alexander.Richardson at cl.cam.ac.uk>
  Date:   2020-01-13 (Mon, 13 Jan 2020)

  Changed paths:
    A lld/test/ELF/mips-eh_frame-pic.s
    M llvm/lib/MC/MCObjectFileInfo.cpp
    M llvm/lib/Object/RelocationResolver.cpp
    M llvm/test/DebugInfo/Mips/eh_frame.ll
    M llvm/test/MC/Mips/eh-frame.s

  Log Message:
  -----------
  [MIPS][ELF] Use PC-relative relocations in .eh_frame when possible

When compiling position-independent executables, we now use
DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a
64-bit PC-relative ELF relocation so we cannot use sdata8 for the large
code model case. When using the large code model, we fall back to the
previous behaviour of generating absolute relocations.

With this change clang-generated .o files can be linked by LLD without
having to pass -Wl,-z,notext (which creates text relocations).
This is simpler than the approach used by ld.bfd, which rewrites the
.eh_frame section to convert absolute relocations into relative references.

I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations
for MIPS ouput at some point. However, I also checked that recent ld.bfd
can process the clang-generated .o files so this no longer seems true.

Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72228


  Commit: 8e8ccf4712cf58562a91c197da3efd4f9963ce0d
      https://github.com/llvm/llvm-project/commit/8e8ccf4712cf58562a91c197da3efd4f9963ce0d
  Author: Alex Richardson <Alexander.Richardson at cl.cam.ac.uk>
  Date:   2020-01-13 (Mon, 13 Jan 2020)

  Changed paths:
    M llvm/lib/Target/Mips/MipsISelLowering.cpp
    M llvm/test/CodeGen/Mips/reloc-jalr.ll

  Log Message:
  -----------
  [MIPS] Don't emit R_(MICRO)MIPS_JALR relocations against data symbols

The R_(MICRO)MIPS_JALR optimization only works when used against functions.
Using the relocation against a data symbol (e.g. function pointer) will
cause some linkers that don't ignore the hint in this case (e.g. LLD prior
to commit 5bab291b7b) to generate a relative branch to the data symbol
which crashes at run time. Before this patch, LLVM was erroneously emitting
these relocations against local-dynamic TLS function pointers and global
function pointers with internal visibility.

Reviewers: atanasyan, jrtc27, vstefanovic
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72571


Compare: https://github.com/llvm/llvm-project/compare/26d2ace9e230...8e8ccf4712cf