Add -fdirect-access-external-data

Add -fdirect-access-external-data

[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.

Please CC me on replies:)

Re: Add -fdirect-access-external-data

[Florian Weimer]

* 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.

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).

Re: Add -fdirect-access-external-data

[H.J. Lu]

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.

Re: 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.

Re: Add -fdirect-access-external-data

[H.J. Lu]

On Wed, Jan 6, 2021 at 10:32 PM Fangrui Song <i@maskray.me> wrote:
>
> 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.

If I understand it correctly, you want to treat all accesses to protected
definitions as local access and all read/write accesses to undefined symbols
should go through GOT.  Branches to undefined symbols can use PLT.
-fdirect-access-external-data doesn't reflect it.

-- 
H.J.

Re: Add -fdirect-access-external-data

[Fangrui Song]

On Thu, Jan 7, 2021 at 6:07 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Wed, Jan 6, 2021 at 10:32 PM Fangrui Song <i@maskray.me> wrote:
> >
> > 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.
>
> If I understand it correctly, you want to treat all accesses to protected
> definitions as local access
> and all read/write accesses to undefined symbols
> should go through GOT.  Branches to undefined symbols can use PLT.
> -fdirect-access-external-data doesn't reflect it.

My apologies. Direct/indirect access to protected definitions is a separate
topic, unrelated to -f[no-]direct-access-external-data.

(
If anyone is interested, there was a heated discussion about accesses to
protected definitions
https://sourceware.org/legacy-ml/binutils/2016-03/msg00312.html basically a lot
of folks considered that copy relocations are best-effort support provided by
the toolchain. For protected symbols, copy relocations do not necessarily work.

Clang always treats protected similar to hidden/internal, no special
logic for x86-64 protected.
)

Branches to undefined symbols is yet another separate topic.

(
On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32
relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer
(2018) GNU as/LLVM integrated assembler.

On i386, there are 2 types of PLTs, PIC and non-PIC. Currently the informal
convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT, but
R_386_PLT32 is arguably preferable for -fno-pic code as well: this can avoid a
"canonical PLT entry" (st_shndx=0, st_value!=0) if the symbol turns out to be
defined externally.

My idea is that we can always use R_386_PLT32 in -fno-pic mode.
)

Taking the address of an external function is related to
-f[no-]direct-access-external-data. A function pointer of an external function
is very similar to external data.

A canonical PLT entry can be caused by either a branch (R_386_PC32/R_386_32)
or an address taken operation (R_386_PC32/R_386_32) if the symbol
turns out to be external.
-fno-direct-access-external-data can only address the function pointer usage.

Re: Add -fdirect-access-external-data

[H.J. Lu]

On Thu, Jan 7, 2021 at 7:45 PM Fangrui Song <i@maskray.me> wrote:
>
> On Thu, Jan 7, 2021 at 6:07 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Wed, Jan 6, 2021 at 10:32 PM Fangrui Song <i@maskray.me> wrote:
> > >
> > > 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.
> >
> > If I understand it correctly, you want to treat all accesses to protected
> > definitions as local access
> > and all read/write accesses to undefined symbols
> > should go through GOT.  Branches to undefined symbols can use PLT.
> > -fdirect-access-external-data doesn't reflect it.
>
> My apologies. Direct/indirect access to protected definitions is a separate
> topic, unrelated to -f[no-]direct-access-external-data.
>
> (
> If anyone is interested, there was a heated discussion about accesses to
> protected definitions
> https://sourceware.org/legacy-ml/binutils/2016-03/msg00312.html basically a lot
> of folks considered that copy relocations are best-effort support provided by
> the toolchain. For protected symbols, copy relocations do not necessarily work.
>
> Clang always treats protected similar to hidden/internal, no special
> logic for x86-64 protected.
> )

Then, function pointer and copy relocation don't work correctly on protected
symbols with clang.  For GCC, function pointer and copy relocation on
protected symbols work correctly today.

> Branches to undefined symbols is yet another separate topic.
>

All these issues are related.

> (
> On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32
> relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer
> (2018) GNU as/LLVM integrated assembler.
>
> On i386, there are 2 types of PLTs, PIC and non-PIC. Currently the informal
> convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT, but
> R_386_PLT32 is arguably preferable for -fno-pic code as well: this can avoid a
> "canonical PLT entry" (st_shndx=0, st_value!=0) if the symbol turns out to be
> defined externally.
>
> My idea is that we can always use R_386_PLT32 in -fno-pic mode.
> )
>
> Taking the address of an external function is related to
> -f[no-]direct-access-external-data. A function pointer of an external function
> is very similar to external data.
>
> A canonical PLT entry can be caused by either a branch (R_386_PC32/R_386_32)
> or an address taken operation (R_386_PC32/R_386_32) if the symbol
> turns out to be external.
> -fno-direct-access-external-data can only address the function pointer usage.

i386 is legacy.  We should leave it alone.  But we should do something
for x86-64.
That is why I proposed an ABI change:

https://groups.google.com/g/x86-64-abi/c/DRvKxJ1AH3Q

What I'd like to see is a compiler option which does

1. In shared object, all accesses to protected definitions can be
treated as local access.
2. In PIE, all read/write accesses to undefined symbols should go through GOT.
3. In PIE and shared object, all global function pointers, whose
function bodies aren't
defined locally, should be resolved to GOT.
4. Branches to undefined symbols use PLT.

-f[no-]direct-access-external-data doesn't properly describe these.
Maybe -fone-global-definition is better.

-- 
H.J.