On Sat, Dec 26, 2020 at 7:39 AM H.J. Lu <hjl.to...@gmail.com> wrote: > > On Sat, Dec 26, 2020 at 7:32 AM Florian Weimer <f...@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.
