[mips] Make the .eh_frame writable on FreeBSD to work around issues in the old linker.

[dsanders]

Summary

The Mips port of FreeBSD is currently using an old linker (GNU ld 2.17.50 [FreeBSD]
2007-07-03) which seems to be unable to fully support read-only .eh_frame sections.
Work around this for now by making them writeable on this target.

The linker must also be patch to support R_MIPS_PC32 as discussed in PR25176.

[• rafael]

Please don't. Just update the linker and use R_MIPS_PC32 in llvm.

[dsanders]

I'm told that they can't update to a newer GNU Ld because FreeBSD chose to reject GPLv3. Their plan as it has been explained to me is to get any build working with clang as the system compiler, then work on making lld the default linker. I therefore see this as a stepping stone for getting to the correct place and would want to revert this patch as soon as I'm able to.

... and use R_MIPS_PC32 in llvm.

Thanks to the linker patch mentioned in PR25176, we are using R_MIPS_PC32 everywhere that Mips Linux targets use them. Unfortunately, this doesn't quite result in a working link. The remaining problem is that this:

.cfi_personality 128, DW.ref.__gxx_personality_v0

emits a R_MIPS_64 reference in .eh_frame. This is the same as what we emit for Linux and modern linkers accept it (and convert to a PC relative form) but this linker doesn't.

I was going to say that I can't change the encoding to 0x9B (indirect, pcrel, sdata4) but when I double checked this it surprised me by working. It resulted in a crash last time I tried this so maybe the linker patch fixed that as well. A FreeBSD-specific personality encoding is much better than this patch so I'll test a bit more and report back.

[dsanders]

Abandoned in favour of D14700

[emaste]

In D14655#288914, @dsanders wrote:

I'm told that they can't update to a newer GNU Ld because FreeBSD chose to reject GPLv3. Their plan as it has been explained to me is to get any build working with clang as the system compiler, then work on making lld the default linker. I therefore see this as a stepping stone for getting to the correct place and would want to revert this patch as soon as I'm able to.

Our plan is indeed to use Clang as the system compiler and LLD as the system linker on all of our supported platforms as they become functional. In the interim we'll use one of these options:

1. Try to work around binutils 2.17.50 limitations
2. Have two versions of binutils in the tree, with a build-time switch
3. Exclude ld from the base system for MIPS, requiring the installation of a binutils port to have a usable toolchain

The third option above is what we do for arm64 today and it works well, but makes bootstrapping a system more awkward. Also upstream binutils lacks FreeBSD/MIPS support, so there's work that needs to be done just to make a newer ld available.

lib/MC/MCObjectFileInfo.cpp

unsigned EHSectionType = T.getArch() == Triple::x86_64
                                : ELF::SHT_PROGBITS;
 
   // Solaris requires different flags for .eh_frame to seemingly every other
   // platform.
   unsigned EHSectionFlags = ELF::SHF_ALLOC;
   if (T.isOSSolaris() && T.getArch() != Triple::x86_64)
     EHSectionFlags |= ELF::SHF_WRITE;
 
+  // The Mips port of FreeBSD currently has difficulty with read only .eh_frame
+  // due to an old linker. Work around this for now by making it writable.
+  if (T.isOSFreeBSD() &&
+      (T.getArch() == Triple::mips || T.getArch() == Triple::mipsel ||
+       T.getArch() == Triple::mips64 || T.getArch() == Triple::mips64el))
+    EHSectionFlags |= ELF::SHF_WRITE;
+
   // ELF
   BSSSection = Ctx->getELFSection(".bss", ELF::SHT_NOBITS,
                                   ELF::SHF_WRITE | ELF::SHF_ALLOC);
 
   TextSection = Ctx->getELFSection(".text", ELF::SHT_PROGBITS,
                                    ELF::SHF_EXECINSTR | ELF::SHF_ALLOC);
 
   DataSection = Ctx->getELFSection(".data", ELF::SHT_PROGBITS,