[Bug target/98112] Add -fdirect-access-external-data & drop HAVE_LD_PIE_COPYRELOC

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112

--- Comment #5 from Fangrui Song <i at maskray dot me> ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Fangrui Song from comment #3)
> > Are you happy with the option name -f[no-]direct-access-external-data ?
> 
> Not at all, no :-(
> 
> The name does not explain its purpose at all, and the whole concept only
> makes sense for a fraction of all targets.

> A -mcopy-relocs ("generate copy
> relocations if that is a good idea"), defined *per target*, would be a lot
> better, or a -mpic-use-copy-relocs (since you say it is *not* just for pie),
> or something like that.

Please read my first comment why copy relocs is a bad name. The compiler
behavior is whether the external data symbol is accessed directly/indirectly.
Copy relocs is just the inferred ELF linker behavior (in -no-pie/-pie link
mode) when the symbol is external. The option name should mention the direct
behavior, instead of the inferred behavior at the linking stage.

-fdirect-access-external-data makes sense on other binary formats, though I
won't ask GCC to
implement relevant behaviors for other binary formats.

* For example, on COFF, the behavior is like always
-fdirect-access-external-data.  __declspec(dllimport) is needed to use indirect
access.
* On Mach-O, the behavior is like -fdirect-access-external-data for -fno-pic
(only available on arm) and the opposite for -fpic.

If you don't want to think of non-ELF, feel free to make the option specific to
ELF.
Also feel free to make it specific to -fno-pic/-fpie (disallowed for -fpic).
I have no plan to implement Clang -fdirect-access-external-data for -fpic as
well.

> You want to have this a generic option, while it is
> not clear at all what it would mean, what it would *do*, which is especially
> important if you want this to be an option used by multiple compilers: if it
> is not clear to every user what simple, sensible thing a flag is the knob
> for, that flag simply cannot be used at all -- or worse, some users *will*
> use it, but then their intentions are not clear to humans, and different
> compilers can (and will!) think the user wanted something else!

To be clear, GCC botched things with the inappropriate HAVE_LD_PIE_COPYRELOC
and I made the proposal to (1) let non-x86-64 leverage the missing optimization
for -pie (2) eventually fix the x86-64 STV_PROTECTED story.
I have considered all the potential simplification of internal representations
for Clang this option will enable.
(llvm/lib/Target/TargetMachine.cpp shouldAssumeDSOLocal can be further
simplified with this option)