From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 2AB01384F6D0 for ; Thu, 17 Nov 2022 21:55:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2AB01384F6D0 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1032.google.com with SMTP id v4-20020a17090a088400b00212cb0ed97eso3261001pjc.5 for ; Thu, 17 Nov 2022 13:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=hXPGlOlMFvrtBg093iVJXiduUf8h6j+S8kZBBvsVR2w=; b=iUsX2fdmbf6wf91hQOn77e/PUkq5HhvFH55wvTDLfESgeZbIsUbmmbKRaiBOA+MAv4 /OdA8dyijJEWrZHLN/PTfW5phkFQjYkviGA3a29T8Di8DmfLMXi5lc/sMUqHJho5bZDs 1XRBDkC96nx0bYAb1UR/IjjDh/0f1K6jyKXRcbSVHOgnDd6XDpF/wdx+EWQWFhe4Epy7 FuQa6C5qvvB4vPdDqko8ZyfqMj5/XYc2pZm3VrfS61GpvJpDYyswZFdRgjmPgXKBS58c JBq6sqCp8FJ2pdZ8E3mYI8zToGJ8d6McA+8zZk7CdhgiTm63z7x9nQNqdz7EQdU7Ft4I 3NLw== 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=hXPGlOlMFvrtBg093iVJXiduUf8h6j+S8kZBBvsVR2w=; b=Qngy0jhp11Pa5HlN5gdhC35eQRe6nwPE7wrWgOXTEMvRDZffJgmDxEZ8C2EXGoQj0W iLJ/7Y5tgA4XiiQN/IHPrsiSJXkOL/vdGGd+Dg8b09p1Z+g+4tYulrU9nTjIV+dIruFd IDTthwYHqeiOdcvtYn3BZO5Xd14f/WaD+gEDsm/HrEDJCqTc0TcQJVU386URcoYUgI1s Sgh8nw5yha4xz0dErgO6iklVvXjNsT6GcX99fmzTWpUgrtCAF8Wpaot9aLGOXwQF5CwV 7DWHPmIJD2XmP82/Y0llG389P/o/UN+LrSLtVhyDFuAvXmT6hnom4sYjAULbZlaN5qFk mTcQ== X-Gm-Message-State: ANoB5pkEtNe9yNH4Wldh3iCKUmt4OHdZDx6rO/BeX7qx1zsLkM1h52GN z+uAMQcCVeQ0OoHLn5EltrJ88jlTSW2H4kZ8AqY= X-Google-Smtp-Source: AA0mqf7q3PoTXgPW7a/pNWKmWYWCYul0AKFMrZwpfYIfKedHkQ09c5YYjFm9L/aCNiPYpuWGNf8CwR5f0jy+YLr9/fw= X-Received: by 2002:a17:902:ab8d:b0:188:62b7:1d6b with SMTP id f13-20020a170902ab8d00b0018862b71d6bmr4579827plr.106.1668722148137; Thu, 17 Nov 2022 13:55:48 -0800 (PST) MIME-Version: 1.0 References: <20221117212006.dspm45znjyqj6ktf@google.com> In-Reply-To: From: Andrew Pinski Date: Thu, 17 Nov 2022 13:55:35 -0800 Message-ID: Subject: Re: [PATCH] AArch64: Add support for -mdirect-extern-access To: Fangrui Song 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=0.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_INFOUSMEBIZ,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: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 GOT = indirection > > > > + on all external data symbols with :option:`-fpie` or :option:`-f= PIE`. This is > > > > + useful for executables linked with :option:`-static` or :option:= `-static-pie`. > > > > + With :option:`-fpic` or :option:`-fPIC`, it only affects accesse= s to protected > > > > + data symbols. It has no effect on non-position independent code= . The default > > > > + is :option:`-mno-direct-extern-access`. > > > > + > > > > + .. warning:: > > > > + > > > > + Use :option:`-mdirect-extern-access` either in shared librarie= s 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. > > > > > > I think current GCC and Clang's behavior is: > > > > > > * -mdirect-extern-access is the default for -fno-pic. This is to enab= le optimizations for -static programs but may introduce copy relocations. > > > * -mno-direct-extern-access is the default for -fpie and -fpic. This = uses some GOT-generating relocations which can be optimized out (lld, see h= ttps://maskray.me/blog/2021-08-29-all-about-global-offset-table) but the in= struction 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-pl= t-entries-and-protected). > > > If -mdirect-extern-access gets more popular, I can add a Clang alias. > > > But I am opposed to forcing a GNU property for -mdirect-extern-access= /-mno-direct-extern-access. > > > > > > FWIW I used https://gist.github.com/MaskRay/c03a90922003df666551589f1= 629df22 to test my Clang changes related to -fno-semantic-interposition > > > on various visibility attributes x non-weak/weak x nopic/pie/pic x dl= limport/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-entries= -and-protected > "Reflection on protected data symbols and copy relocations" > GCC 5 x86-64 made a change and GCC aarch64 accidentally picked up the cha= nge. You missed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65248 (or rather r5-7961-ga5eef8e9b02474 ) was the change to fix protected . > > """ > 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=3Dcbddf64c0243816b45e66= 80754a251c603245dbc. 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 "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 for 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 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 > > > >> >> > > > >> >> If this is LLVM's default for PIC (and by assumption shared lib= raries), > > > >> >> is it then invalid to use -mdirect-extern-access for any PIEs t= hat > > > >> >> are linked against those shared libraries and use protected sym= bols > > > >> >> from those libraries? How would a user know that one of the sh= ared > > > >> >> libraries they're linking against was built in this way? > > > >> > > > > >> > Yes, the usage model is that you'd either use it for static PIE = or only on > > > >> > data that is not shared. If you get it wrong them you'll get the= copy > > > >> > relocation error. > > > >> > > > >> Thanks. I think I'm still missing something though. If, for the > > > >> non-executable case, people should only use the feature on data th= at > > > >> is not shared, why do we need to relax the binds-local condition f= or > > > >> protected symbols on -fPIC? Oughtn't the symbol to be hidden rath= er > > > >> 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 the > > > >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