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.

Reply via email to