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.