On Fri, Sep 24, 2021 at 10:29 AM Fāng-ruì Sòng <mask...@google.com> wrote:
>
>  On Tue, Sep 21, 2021 at 7:08 PM Fāng-ruì Sòng <mask...@google.com> wrote:
> >
> > On Tue, Sep 21, 2021 at 6:57 PM H.J. Lu <hjl.to...@gmail.com> wrote:
> > >
> > > On Tue, Sep 21, 2021 at 9:16 AM Uros Bizjak <ubiz...@gmail.com> wrote:
> > > >
> > > > On Mon, Sep 20, 2021 at 8:20 PM Fāng-ruì Sòng via Gcc-patches
> > > > <gcc-patches@gcc.gnu.org> wrote:
> > > > >
> > > > > PING^5 https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html
> > > > >
> > > > > On Sat, Sep 4, 2021 at 12:11 PM Fāng-ruì Sòng <mask...@google.com> 
> > > > > wrote:
> > > > > >
> > > > > > PING^4 
> > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html
> > > > > >
> > > > > > One major design goal of PIE was to avoid copy relocations.
> > > > > > The original patch for GCC 5 caused problems for many years.
> > > > > >
> > > > > > On Wed, Aug 18, 2021 at 11:54 PM Fāng-ruì Sòng <mask...@google.com> 
> > > > > > wrote:
> > > > > >>
> > > > > >> PING^3 
> > > > > >> https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html
> > > > > >>
> > > > > >> On Fri, Jun 4, 2021 at 3:04 PM Fāng-ruì Sòng <mask...@google.com> 
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > PING^2 
> > > > > >> > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html
> > > > > >> >
> > > > > >> > On Mon, May 24, 2021 at 9:43 AM Fāng-ruì Sòng 
> > > > > >> > <mask...@google.com> wrote:
> > > > > >> > >
> > > > > >> > > Ping 
> > > > > >> > > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html
> > > > > >> > >
> > > > > >> > > On Tue, May 11, 2021 at 8:29 PM Fangrui Song 
> > > > > >> > > <mask...@google.com> wrote:
> > > > > >> > > >
> > > > > >> > > > This was introduced in 2014-12 to use local binding for 
> > > > > >> > > > external symbols
> > > > > >> > > > for -fPIE. Now that we have H.J. Lu's GOTPCRELX for years 
> > > > > >> > > > which mostly
> > > > > >> > > > nullify the benefit of HAVE_LD_PIE_COPYRELOC, 
> > > > > >> > > > HAVE_LD_PIE_COPYRELOC
> > > > > >> > > > should retire now.
> > > > > >> > > >
> > > > > >> > > > One design goal of -fPIE was to avoid copy relocations.
> > > > > >> > > > HAVE_LD_PIE_COPYRELOC has deviated from the goal.  With this 
> > > > > >> > > > change, the
> > > > > >> > > > -fPIE behavior of x86-64 will be closer to x86-32 and other 
> > > > > >> > > > targets.
> > > > > >> > > >
> > > > > >> > > > ---
> > > > > >> > > >
> > > > > >> > > > See https://gcc.gnu.org/legacy-ml/gcc/2019-05/msg00215.html 
> > > > > >> > > > for a list
> > > > > >> > > > of fixed and unfixed (e.g. gold incompatibility with 
> > > > > >> > > > protected
> > > > > >> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=19823) 
> > > > > >> > > > issues.
> > > > > >> > > >
> > > > > >> > > > If you prefer a longer write-up, see
> > > > > >> > > > https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected
> > > > > >> > > > ---
> > > > > >> > > >  gcc/config.in                                 |  6 ---
> > > > > >> > > >  gcc/config/i386/i386.c                        | 11 +---
> > > > > >> > > >  gcc/configure                                 | 52 
> > > > > >> > > > -------------------
> > > > > >> > > >  gcc/configure.ac                              | 48 
> > > > > >> > > > -----------------
> > > > > >> > > >  gcc/doc/sourcebuild.texi                      |  3 --
> > > > > >> > > >  .../gcc.target/i386/pie-copyrelocs-1.c        | 14 -----
> > > > > >> > > >  .../gcc.target/i386/pie-copyrelocs-2.c        | 14 -----
> > > > > >> > > >  .../gcc.target/i386/pie-copyrelocs-3.c        | 14 -----
> > > > > >> > > >  .../gcc.target/i386/pie-copyrelocs-4.c        | 17 ------
> > > > > >> > > >  gcc/testsuite/lib/target-supports.exp         | 47 
> > > > > >> > > > -----------------
> > > > > >> > > >  10 files changed, 2 insertions(+), 224 deletions(-)
> > > > > >> > > >  delete mode 100644 
> > > > > >> > > > gcc/testsuite/gcc.target/i386/pie-copyrelocs-1.c
> > > > > >> > > >  delete mode 100644 
> > > > > >> > > > gcc/testsuite/gcc.target/i386/pie-copyrelocs-2.c
> > > > > >> > > >  delete mode 100644 
> > > > > >> > > > gcc/testsuite/gcc.target/i386/pie-copyrelocs-3.c
> > > > > >> > > >  delete mode 100644 
> > > > > >> > > > gcc/testsuite/gcc.target/i386/pie-copyrelocs-4.c
> > > >
> > > > From x86 maintainer's PoV, the implementation is trivially correct,
> > > > but I have no idea about functionality. HJ, can you please review the
> > > > functionality and post your opinion on the patch to move it forward?
> > > >
> > > > Thanks,
> > > > Uros.
> > >
> > > I prefer to leave it alone and apply this:
> > >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576736.html
> > >
> > > instead.  I am working to add a nodirect_extern_access attribute based
> > > on feedback at LPC 2021.
> >
> > I think -fpie should be fixed as soon as possible.
> >
> > "Add -f[no-]direct-extern-access" says "-fdirect-extern-access is the 
> > default."
> > IMHO this is not a good choice for -fpie.
> > As the description of this patch says, one of the design goals of
> > -fpie is to avoid copy relocations.
> >
> > > In executable and shared library, bind symbols with the STV_PROTECTED 
> > > visibility locally
> >
> > As I have repeated many times (also Clang's behavior), STV_PROTECTED
> > visibility symbol should be bound locally regardless of
> > -fno-direct-extern-access.
> >
> > I think it is fair to say all of Michael Matz, Alan Modra, and I think
> > adding so many behaviors under -fno-direct-extern-access is
> > over-engineering (well, because I don't think
> > -fno-direct-extern-access can be selected as the default behavior any
> > time soon).
> >
> > https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected#summary
>
> -fno-direct-extern-access should focus on the semantics of non-pic
> code, which is the traditional configuration which may introduce copy
> relocations.
> An important design goal of -fpie/-fPIE was to avoid copy relocations.
> The 2014 x86-64 patch deviated the direction (I am sorry that some
> Google folks originated it) and the revert is long due. I am glad that
> all other architectures still keep the nice property that -fpie/-fPIE
> never introduces copy relocations.
>
> -fdirect-extern-access can do something with -fpie/-fPIE but I doubt
> anyone may enable it to get the small size benefit.
> The -f(no-)?direct-extern-access patch doesn't need to check
> HAVE_LD_PIE_COPYRELOC.
> The few users (if ever exist) who use -fpie -fdirect-extern-access
> should ensure their GNU ld supports copy relocations by themselves.
> GCC configure doesn't need to pay the availability check cost. The
> support has been available for many years (~2014/2015).

I'd like to get rid of copy relocation for both PIE and non-PIE.  But
we should keep copy relocation as an option for both PIE and non-PIE
if people ask for it.

-- 
H.J.

Reply via email to