Linkers do not currently support PT_GNU_RELRO for SHF_X86_64_LARGE
sections; that would require the linker to emit more than one
PT_GNU_RELRO because large sections are discontiguous by design,
and most ELF dynamic loaders do not support that (bionic appears to
support it but glibc/musl/FreeBSD/NetBSD/OpenBSD appear not to). With
current linkers these sections will end up in .ldata which results
in silently disabling RELRO. Therefore, disable SHF_X86_64_LARGE for
RELRO sections. If this ever gets supported by downstream components
in the future we could add an opt-in flag for moving these sections
to .ldata.rel.ro which would trigger the creation of a second
PT_GNU_RELRO.

Reviewers: MaskRay, aeubanks

Reviewed By: aeubanks

Pull Request: https://github.com/llvm/llvm-project/pull/137742

If multiple globals are placed in an explicit section, there's a chance
that the large data threshold will cause the different globals to be
inconsistent in whether they're large or small. Mixing sections with
mismatched large section flags can cause undesirable issues like
increased relocation pressure because there may be 32-bit references to
the section in some TUs, but the section is considered large since input
section flags are unioned and other TUs added the large section flag.

An explicit code model on the global still overrides the decision. We
can do this for globals without any references to them, like what we did
with asan_globals in #74514. If we have some precompiled small code
model files where asan_globals is not considered large mixed with
medium/large code model files, that's ok because the section is
considered large and placed farther. However, overriding the code model
for globals in some TUs but not others and having references to them
from code will still result in the above undesired behavior.

This mitigates a whole class of mismatched large section flag issues
like what #77986 was trying to fix.

This ends up not adding the SHF_X86_64_LARGE section flag on explicit
sections in the medium/large code model. This is ok for the large code
model since all references from large text must use 64-bit relocations
anyway.

This reverts commit 19fff858931bf575b63a0078cc553f8f93cced20.

Now that explicit large globals are handled properly in the small code model.

This reverts commit 323451ab88866c42c87971cbc670771bd0d48692.

Code with these section names in the wild doesn't compile because
support for large globals in the small code model is not complete yet.

Using the GlobalVariable code_model property added in #72077.

code_model = "small" means the global should be treated as small
regardless of the TargetMachine code model.
code_model = "large" means the global should be treated as large
regardless of the TargetMachine code model.

Inferring small/large based on a known section name still takes
precedence for correctness.

The intention is to use this for globals that are accessed very
infrequently but also take up a lot of space in the binary to mitigate
relocation overflows. Prime examples are globals that go in
"__llvm_prf_names" for coverage/PGO instrumented builds and
"asan_globals" for ASan builds.

Globals marked with the .lbss/.ldata/.lrodata should automatically be
treated as large.
Do this regardless of the code model for consistency when mixing object
files compiled with different code models.

Basically the other half of #70748.

Example in the wild:
https://codebrowser.dev/qt5/qtbase/src/testlib/qtestcase.cpp.html#1664

This allows better interoperability mixing small/medium/large code model
code since large code model data can be put into separate large
sections.

And respect large data threshold under large code model.
gcc also does this: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html.

See https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU.

Commit f3ea73133f91c1c23596d45680c8f2269c1dd289 allows SHF_X86_64_LARGE
for all global variables with an explicit section. For the following
variables, their data sections will be annotated as SHF_X86_64_LARGE.

```
const char relro[512] __attribute__((section(".rodata"))) = "a";
const char *const relro __attribute__((section(".data.rel.ro"))) = "a";
char data[512] __attribute__((section(".data"))) = "a";
```

The typical linker requirement is that we do not create more than one
output section with the same name, and the only output section should
have the bitwise OR value of all input section flags. Therefore, the
output .data section will have the SHF_X86_64_LARGE flag and be
moved away from the regular sections. This is undesired but benign.
However, .data.rel.ro having the SHF_X86_64_LARGE flag is problematic
because dynamic loaders do not support more than one PT_GNU_RELRO
program header, and LLD produces the error
`error: section: .jcr is not contiguous with other relro sections`.

I believe the most appropriate solution is to disallow SHF_X86_64_LARGE
on variables with an explicit section of certain prefixes (
.bss/.data/.bss) and allow others (e.g. metadata sections for various
instrumentation). Fortunately, global variables with an explicit
.bss/.data/.bss section are rare, so they should not cause excessive
relocation overflow pressure.

An oversight in https://reviews.llvm.org/D148836 since this is a
different code path.

Otherwise they may mistakenly get the large section flag.