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

["segher at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #6 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Fangrui Song from comment #5)
> Please read my first comment why copy relocs is a bad name.

Since I reply to some of that (namely, your argument 1)), you could assume I
have read your comment already ;-)

> The compiler
> behavior is whether the external data symbol is accessed
> directly/indirectly.

Not really, no.  It isn't clear at all what "directly" even means!

> 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.

Yes.  But your proposed solution just makes this worse :-(

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

But what does that *mean*?  "direct access"?  (And, "external data", for that
matter!  This isn't as obvious as it was thirty years ago.)

> * For example, on COFF, the behavior is like always
> -fdirect-access-external-data.  __declspec(dllimport) is needed to use
> indirect access.

I don't know what "declspec" is.  Something something mswindows?

> * On Mach-O, the behavior is like -fdirect-access-external-data for -fno-pic
> (only available on arm) and the opposite for -fpic.

So what you want is that object that are globally visible will be implemented
as-is?  For if you do not do whole-program optimisation, for example?  So that
a) those objects will actually *exist*, and b) they will be laid out in the way
the program expects?

> If you don't want to think of non-ELF, feel free to make the option specific
> to ELF.

The problem is not that I don't want to think about it, but that the way it
seems to be defined only applies to ELF (and to some specific (sub-)targets
using ELF, even).

> > 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

Huh?  That isn't a user-visible thing at all, it's an implementation detail.
It is a quite straight-forward autoxxxx thing, defined to true if the loader
passes some specific test.

- o - o -

So, what you want is to attach the attribute ((used)) variable attribute to all
data (or at least the data not explicitly made static) automatically?