Should LLD not set the RELRO program header when targeting -maarch64elf?

[nickdesaulniers]

Bugzilla Link	48549
Version	unspecified
OS	All
Blocks	#4440
CC	@MaskRay,@kbeyls,@smithp35,@stephenhines

Extended Description

In
https://lore.kernel.org/lkml/20201214231827.GG8873@bubble.grove.modra.org/
Alan Modra notes about BFD:

The default linker emulation for an aarch64-linux ld.bfd is
-maarch64linux, the default for an aarch64-elf linker is
-maarch64elf. They are not equivalent. If you choose -maarch64elf
you get an emulation that doesn't support -z relro.

Should LLD not set the RELRO program header when targeting -maarch64elf to better match compatibility with GNU BFD?

[nickdesaulniers]

Related BFD bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27093

[MaskRay]

I think LLD defaulting to -z relro might not be a good choice.
Such a choice is better off implemented in the compiler drivers, like what some GCC distributions and some Clang implemented toolchains do. GCC/Clang never pass -z norelro to the linker.

Unfortunately it is difficult and impractical to change the default at this point: the removal of PT_GNU_RELRO will break 238 tests (a program header can affect the addresses of all sections).
A larger issue is that some ELF features depend on ELFOSABI_GNU: STT_GNU_IFUNC, STB_GNU_UNIQUE (misfeature considered by many folks), SHT_GNU_ver*. While they are called GNU, many other OSes like FreeBSD (and other *BSD and probably Fuchsia) have adopted many such features.

On generic-abi, there was even a discussion "[ld] Allow custom sections to be under PT_GNU_RELRO".
(OK, I started the discussion when I heard from llvm-dev some Android folks wanted to make custom sections RELRO.)
I believe many OSes will favor the idea but Solaris/HP-UX folks did not like the idea so a generic RELRO became a dead end.

So the linkers are making different trade-offs here (for LLD, we have less legacy burden, somewhat less compatibility burden with GNU ld, we don't want to add OS-specific customizations, relro has become something set in stone), so personally I think this is probably a wontfix.
(If someone develops a smart FileCheck updating test cases automatically, I don't mind whether -z norelro is the default - just keep in mind there are 238 tests :))

(If such a smart FileCheck exists, I can proceed with my https://reviews.llvm.org/D76561 (Default to dso_local for function definitions), which can reduce 'dso_local' related differences between ELF/COFF .ll files)

[MaskRay]

Perhaps it would be nicer lld didn't default to -z relro. Now it seems that wontfix is a realistic state as we don't plan to complex the code for this corner case.