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?
