From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 2BF153852215 for ; Thu, 17 Nov 2022 21:37:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2BF153852215 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-pg1-x531.google.com with SMTP id q1so3229856pgl.11 for ; Thu, 17 Nov 2022 13:37:52 -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=zpz0l05HdOQ2L+hTvQxtyiM/SHbKV+2aCLWUjmkk9oM=; b=ZmeCD6kvWP5Iho9n5PovvRm6l0GORTSM0nNRlShw24M3Td52lFLlZ1HnYhdsO9txAH ZFTu+0Wpaaam6v17MqTDvV2KLbbqVdCmeKeeQEHkW4PgSj/JBgz8pjCkdFToaI6X/07/ 3Snu0LIkJiBiuCWkNpDBqIAVsOy9VTRSxhAezocnLqyRxmRjhba4ac1Kt/5Hh7+ll/3N g0F0kwUv7d+NLA2RjE5iZM6N6lOoT/SIpKI2GSV9W/dwnDN70ASQFirjFB6EaBxBbfub GSqU2MKT43cNgfAsePGiz++MALEOyvLElILhOqEaPvHeQmDOvvcGjiFqUtOR+Rp4Z/5p bn+Q== 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=zpz0l05HdOQ2L+hTvQxtyiM/SHbKV+2aCLWUjmkk9oM=; b=V2kagJcVu9w882l858PYXLGlbuxg92ymITbyfaCELWyA3iJc4EpKtmoUAAEO/b0ik/ oVOrs1zH3A5SH//A58+rl6xSKRNW14fTRFXbZx6Ibb0f1jKlK3ADWH2WKTy0vzQ+1Kl2 AxNvSDAkj7+wiVzKTU461oljRLLUgukIAWgUqGm5f2fBhgJw5/QV2PMQ0iZVWX2jWUjh 3JvKCoMjGFRwYmggp7ZKgmWKEW+fsXjr5IEKuY5XNBTyKXC0aidtteFdjRI6RK/KPbmO W/5/ioVYenZRul2Z2dTiuZHyiyDfSHSMwdou5Ofm4eoYcTM/3q+eB4Ks2DTxGBHrYAhI uVuw== X-Gm-Message-State: ANoB5plAi2MqP9BR+zIUv3snerwR6lzeiRNOw8QtNEsJoj/jV5LSvtPf /oRdHhIKkGzFZm42BWlHMsS+hlgE4h7C7Qup4ws= X-Google-Smtp-Source: AA0mqf4hmc2mz6eAx2YVKDrNxJtlD3XxaApu9jcb0e8SthVzshvX0sVQ81fh1xapiLYApgTWOTXcVmJq4y+trNrmqDw= X-Received: by 2002:aa7:9473:0:b0:573:28c6:27fd with SMTP id t19-20020aa79473000000b0057328c627fdmr104069pfq.52.1668721071164; Thu, 17 Nov 2022 13:37:51 -0800 (PST) MIME-Version: 1.0 References: <20221117212006.dspm45znjyqj6ktf@google.com> In-Reply-To: <20221117212006.dspm45znjyqj6ktf@google.com> From: Andrew Pinski Date: Thu, 17 Nov 2022 13:37:38 -0800 Message-ID: Subject: Re: [PATCH] AArch64: Add support for -mdirect-extern-access To: "maskray@google.com" 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=-1.1 required=5.0 tests=BAYES_00,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: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 indi= rection > > + on all external data symbols with :option:`-fpie` or :option:`-fPIE`= . This is > > + useful for executables linked with :option:`-static` or :option:`-st= atic-pie`. > > + With :option:`-fpic` or :option:`-fPIC`, it only affects accesses to= protected > > + data symbols. It has no effect on non-position independent code. T= he default > > + is :option:`-mno-direct-extern-access`. > > + > > + .. warning:: > > + > > + Use :option:`-mdirect-extern-access` either in shared libraries or= in > > + executables, but not in both. Protected symbols used both in a sh= ared > > + library and executable may cause linker errors or fail to work cor= rectly. > > I think current GCC and Clang's behavior is: > > * -mdirect-extern-access is the default for -fno-pic. This is to enable o= ptimizations 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 https= ://maskray.me/blog/2021-08-29-all-about-global-offset-table) but the instru= ction 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-en= tries-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/-mn= o-direct-extern-access. > > FWIW I used https://gist.github.com/MaskRay/c03a90922003df666551589f1629d= f22 to test my Clang changes related to -fno-semantic-interposition > on various visibility attributes x non-weak/weak x nopic/pie/pic x dllimp= ort/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 > > 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 libraries = 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 c= orrectly > >> >> > >> >> If this is LLVM's default for PIC (and by assumption shared librari= es), > >> >> is it then invalid to use -mdirect-extern-access for any PIEs that > >> >> are linked against those shared libraries and use protected symbols > >> >> 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 PIE or o= nly on > >> > data that is not shared. If you get it wrong them you'll get the cop= y > >> > 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 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 rather > >> 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`.