Add -fdirect-access-external-data

[Fangrui Song]

On Sat, Dec 26, 2020 at 7:39 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Sat, Dec 26, 2020 at 7:32 AM Florian Weimer <fw@deneb.enyo.de> wrote:
> >
> > * Fangrui Song:
> >
> > > Hi, I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 which
> > > proposes -fdirect-access-external-data to address some x86-64
> > > GCC/binutils pain[1] and also benefit non-x86 architectures (also see [1]
> > > it can prevent copy relocations).
> > >
> > > [1] Mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112#c2
> > >
> > > Since I am going to add this option to Clang and I hope (once GCC decides to
> > > implement this option the two compilers can use the same option name), I bring
> > > it to your attention.
> >
> > One worry I have is that people start building shared objects with
> > direct data access, expecting the main program to be built with
> > indirect access.  We already see this today with Qt.  It's not really
> > supported well by the toolchain and causes frequent issues.
>
> It can be solved by ABI extension implemented in linker, ld.so and
> compiler.
>
> > Depending on the ELF ABI in question, the new pair of -f options might
> > not actually be meaningful.  It really depends on whether you have
> > reasonably-sized displacements available.  I think there are some ABIs
> > where the optimization is theoretically possible, but impractical
> > because the ilimit it imposes on data segment (think AArch64 without
> > adrp).
>
>
>
> --
> H.J.

Please check out new comments on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112

-fdirect-access-external-data is still the best name. The option is
useful to avoid copy relocations / "canonical PLT entry"
(st_shndx=0,st_value!=0) in -fno-pic code.
I will proceed with my Clang patch.