From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by sourceware.org (Postfix) with ESMTPS id 7BDD1384F6C6 for ; Thu, 17 Nov 2022 22:07:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7BDD1384F6C6 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-yb1-xb2d.google.com with SMTP id j2so3564709ybb.6 for ; Thu, 17 Nov 2022 14:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+vuKrV0+6ODQklhKKSgYGEgxEjIA90p6R5E0017QyC4=; b=RwY3PM7SxUvVPVmr8pQ9uI8NWK4QYVfv/nuD+/9xHIk+7ktX5dHfIQq1tLNcxROzFb hhUa3n3R4WIpS+z2e9QVziiJD4wq77gDknkEAjl11KqMXMjyLHMgw6K+/2UBoPQ7IMS3 YLhTMuEAMa8+0ljYm2EwSJxyVH0qwCpz5SoCMr+OrmR7qakOMJJ1QG4poVlV63j+eTHZ 8iwpHdzM+tTtiAJnQwC6LVL4zk5N1x8z/RA8hBPk2tYG3kvJtih9e8nGixwJypYotVQn H2Lp3FTokqoNiyR7JhAakqZJHXx3hn65ORlA0MFdXm1TBxghWpAqehJguVMvpyUtTmhW ouuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+vuKrV0+6ODQklhKKSgYGEgxEjIA90p6R5E0017QyC4=; b=tIievc+HuHOFm23kgLX4KHYfPA+x/wVn97sVvLjMsfLLQ7WbPyCLFpH7fPCmO5nwfs OgrosR7cAJJNxdDdZqVL2kqRxJ7Fo1JDSEvFWiWJsryu1CLYPrMHULC47Rea7K9YX0Mx 1V/RBL3OE9npEiiKNszkHD6uNkVpeuvjVvvslEAKvOVxJKbvrZQYBDMzI1b4//LmLnpp rxZcHm+xe0srUu5SFR0SV1z1RGRgwXipUfBk8XJii0lOi2lYPQBAPKvdcowDcNvtbLXR 203g4cILAPCadevXcqLUyBoAkEsPcTss8h0TDuetphakqoF1Y9JVGWNZp2jxvRFiEc6A N9bg== X-Gm-Message-State: ANoB5plDvZfuVhYK3uUgdCuTWOytfGRGvC/B1qaY1TZk3PLRddRwNVml +T1WeWNEX3ExTVZn25EDA7a5S8xxlg97013Aa9uN0Q== X-Google-Smtp-Source: AA0mqf69dlw2dgrmngBQ13ppQdQB4jf70TKSh1kcgL8+knBxhaR+SG5V6kiGQCp8j+2kfiJY07OXGCQD7ddq137jM38= X-Received: by 2002:a25:500f:0:b0:6de:2fda:9839 with SMTP id e15-20020a25500f000000b006de2fda9839mr4067101ybb.516.1668722867543; Thu, 17 Nov 2022 14:07:47 -0800 (PST) MIME-Version: 1.0 References: <20221117212006.dspm45znjyqj6ktf@google.com> In-Reply-To: From: Fangrui Song Date: Thu, 17 Nov 2022 14:07:35 -0800 Message-ID: Subject: Re: [PATCH] AArch64: Add support for -mdirect-extern-access To: Andrew Pinski Cc: Wilco Dijkstra , Richard Sandiford , Ramana Radhakrishnan , GCC Patches , Kyrylo Tkachov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-16.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,KAM_INFOUSMEBIZ,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Nov 17, 2022 at 1:55 PM Andrew Pinski wrote: > > On Thu, Nov 17, 2022 at 1:46 PM Fangrui Song wrote: > > > > On Thu, Nov 17, 2022 at 1:37 PM Andrew Pinski wrote= : > > > > > > On Thu, Nov 17, 2022 at 1:21 PM maskray--- via Gcc-patches > > > wrote: > > > > > > > > > +.. option:: -mdirect-extern-access, -mno-direct-extern-access > > > > > + > > > > > + Use direct accesses for external data symbols. It avoids a GO= T indirection > > > > > + on all external data symbols with :option:`-fpie` or :option:`= -fPIE`. This is > > > > > + useful for executables linked with :option:`-static` or :optio= n:`-static-pie`. > > > > > + With :option:`-fpic` or :option:`-fPIC`, it only affects acces= ses to protected > > > > > + data symbols. It has no effect on non-position independent co= de. The default > > > > > + is :option:`-mno-direct-extern-access`. > > > > > + > > > > > + .. warning:: > > > > > + > > > > > + Use :option:`-mdirect-extern-access` either in shared librar= ies or in > > > > > + executables, but not in both. Protected symbols used both i= n a shared > > > > > + library and executable may cause linker errors or fail to wo= rk correctly. > > > > > > > > I think current GCC and Clang's behavior is: > > > > > > > > * -mdirect-extern-access is the default for -fno-pic. This is to en= able optimizations for -static programs but may introduce copy relocations. > > > > * -mno-direct-extern-access is the default for -fpie and -fpic. Thi= s uses some GOT-generating relocations which can be optimized out (lld, see= https://maskray.me/blog/2021-08-29-all-about-global-offset-table) but the = instruction is nevertheless slightly longer. > > > > > > > > (-mdirect-extern-access for -fpic probably doesn't make sense.) > > > > > > > > The option I introduced to Clang is -fdirect-access-external-data > > > > (see https://maskray.me/blog/2021-01-09-copy-relocations-canonical-= plt-entries-and-protected). > > > > If -mdirect-extern-access gets more popular, I can add a Clang alia= s. > > > > But I am opposed to forcing a GNU property for -mdirect-extern-acce= ss/-mno-direct-extern-access. > > > > > > > > FWIW I used https://gist.github.com/MaskRay/c03a90922003df666551589= f1629df22 to test my Clang changes related to -fno-semantic-interposition > > > > on various visibility attributes x non-weak/weak x nopic/pie/pic x = dllimport/not x ... > > > > > > > > > The x86_64 discussion about this is here > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98112 . > > > I think clang changing the ABI is just broken and should think twice > > > before we do it for GCC. > > > > > > And there is a lot of visibility protected issues filed in GCC bug > > > databases specifically about copy relocs too. > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D56527 > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D37611 > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D19520 > > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D28875 > > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D28877 > > > I also suspect clang's behavior is still broken too. > > > > > > Thanks, > > > Andrew > > > > Well, I don't think Clang changed ABI regarding -fno-pic/-fpie/-fpic. > > As I did archaeology on > > https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entri= es-and-protected > > "Reflection on protected data symbols and copy relocations" > > GCC 5 x86-64 made a change and GCC aarch64 accidentally picked up the c= hange. > > You missed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65248 (or > rather r5-7961-ga5eef8e9b02474 ) was the change to fix protected . I didn't. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65248 proposed a p= roblem. It could be resolved as "wontfix. copy relocations are just incompatible with protected symbols as an optimization (which is the very purpose of inventing protected)" but was resolved by pessimizing GCC codegen. This led to heated discussion in several places including https://sourceware.org/legacy-ml/binutils/2016-03/msg00312.html (which my article linked to). > > > > > """ > > On the GCC side, in -fpic mode, using GOT-generating relocations when > > accessing a protected variable subverts the point using the protected > > visibility. The unneeded pessimization is the foremost complaint. The > > pessimization applies to all ports with #define TARGET_BINDS_LOCAL_P > > default_binds_local_p_2. aarch64 moved to default_binds_local_p_2 > > accidentally by > > https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3Dcbddf64c0243816b45e= 6680754a251c603245dbc. > > This was NOT by accident. In fact you just looked into the commit and > NOT the actually email which submitted the patch: > https://gcc.gnu.org/legacy-ml/gcc-patches/2015-04/msg01432.html > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65780 This aarch64 commit was by accident. The code happened to change both COMMON symbol and protected behaviors. While the COMMON symbol behavior was intentional, the proteced symbol behavior was not. > "As s390/arm/aarch64 seems to work fine > (generate a COPY relocation and thus define symbol locally) in non-PIE > executables, this patch changes those to a function that has been added f= or > that behavior." > > > Thanks, > Andrew Pinski > > > > > For GCC<5 (and all versions of Clang), direct accesses to protected > > variables are produced in -fpic code. Mixing such object files can > > still silently break copy relocations on protected data symbols. > > Therefore, GNU ld made the controversial change > > https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;a=3Dcommit;h= =3Dca3fe95e469b9daec153caa2c90665f5daaec2b5 > > to error in -shared mode. > > """ > > > > > > > > > > > > On 2022-11-17, Ramana Radhakrishnan wrote: > > > > >On Thu, Nov 17, 2022 at 5:30 PM Richard Sandiford via Gcc-patches > > > > > wrote: > > > > >> > > > > >> Wilco Dijkstra writes: > > > > >> > Hi Richard, > > > > >> > > > > > >> >> Can you go into more detail about: > > > > >> >> > > > > >> >> Use :option:`-mdirect-extern-access` either in shared libr= aries or in > > > > >> >> executables, but not in both. Protected symbols used both= in a shared > > > > >> >> library and executable may cause linker errors or fail to = work correctly > > > > >> >> > > > > >> >> If this is LLVM's default for PIC (and by assumption shared l= ibraries), > > > > >> >> is it then invalid to use -mdirect-extern-access for any PIEs= that > > > > >> >> are linked against those shared libraries and use protected s= ymbols > > > > >> >> from those libraries? How would a user know that one of the = shared > > > > >> >> libraries they're linking against was built in this way? > > > > >> > > > > > >> > Yes, the usage model is that you'd either use it for static PI= E or only on > > > > >> > data that is not shared. If you get it wrong them you'll get t= he copy > > > > >> > relocation error. > > > > >> > > > > >> Thanks. I think I'm still missing something though. If, for th= e > > > > >> non-executable case, people should only use the feature on data = that > > > > >> is not shared, why do we need to relax the binds-local condition= for > > > > >> protected symbols on -fPIC? Oughtn't the symbol to be hidden ra= ther > > > > >> than protected if the data isn't shared? > > > > >> > > > > >> I can understand the reasoning for the PIE changes but I'm still > > > > >> struggling with the PIC-but-not-PIE bits. > > > > > > > > > >I think I'm with Richard S on hidden vs protected on first reading= . I > > > > >can see why this works out of the box and can even be default for > > > > >static-pie. > > > > > > > > > >Any reason why this is not on by default - it's early enough in th= e > > > > >stage3 cycle and we can always flip the defaults if there are more > > > > >problems found. > > > > > > > > > >You probably need a rebase for the documentation bits,. > > > > > > > > > >regards > > > > >Ramana > > > > > > > > > > > > > > >Ramana > > > > > > > > > > > > + is :option:`-mno-direct-extern-access`. > > > > > > > > -- > > =E5=AE=8B=E6=96=B9=E7=9D=BF --=20 =E5=AE=8B=E6=96=B9=E7=9D=BF