From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by sourceware.org (Postfix) with ESMTPS id 8D7553851C19; Tue, 22 Jun 2021 18:15:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8D7553851C19 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-f174.google.com with SMTP id d12so3221453pgd.9; Tue, 22 Jun 2021 11:15:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XMDApMyKVajj9yl5P8YnOt9CMlyaEnn30Ty6yrgR5aI=; b=O3w3Sb2dPQ/hEZJVgQoTL9u5g5bM4DhFl7ZlfN7X8xdtHsSCON7zKheJm4jY2LjGxW T5w1Y1pyZ85qN1b/E8T8oMDmtcvrUgPjnS21A4U1sHCHYy+LEVmAgkEhBK9arhpLWfIu JP81tta/CLA5cO7edE6Z1QfjcOJVR0JVHnmTUxDywz520OQkomBVVM9/dtnQxT/c7np+ z2MX+25/wpeFNIlIiyy1xdOwTcJZRchSBjX1n2XBHvJXbtmnxHT9xwPBQHSoeyBMo0EX bTIzO4Jp+fEWMsohx8TXbI2euzhunXE9eIR1ib1GT8q0HuLbZ3oiIgoKsSLMj+Ps+9EQ ak7w== X-Gm-Message-State: AOAM530JqmhQoXl7aOytop3z2cDzVS20x/pVW4TBfwf28hGG3wvygNyy 0FOQ4nd8pbannKRjzAvOj5I= X-Google-Smtp-Source: ABdhPJws1R89KyXJEcgkufiPyI6AgovK6q+jX+2Jf3cHsDx1K8HUbvs9fiu/St99L+gqvKW17g/r0Q== X-Received: by 2002:a63:4e4d:: with SMTP id o13mr4923695pgl.361.1624385715533; Tue, 22 Jun 2021 11:15:15 -0700 (PDT) Received: from localhost ([2601:647:4b01:ae80:2c67:2bf7:4730:cb8e]) by smtp.gmail.com with ESMTPSA id em14sm2932590pjb.25.2021.06.22.11.15.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Jun 2021 11:15:15 -0700 (PDT) Date: Tue, 22 Jun 2021 11:15:14 -0700 From: Fangrui Song To: "H.J. Lu" Cc: GCC Patches , Alan Modra , Florian Weimer , Richard Earnshaw , Binutils , hubicka@gcc.gnu.org Subject: Re: [PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check Message-ID: <20210622181514.uobmkb5hyzspzvcz@gmail.com> References: <20210621223438.efryfvivh2lrzcep@gmail.com> <20210622054639.gti363y2dqpjawaa@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 18:15:18 -0000 On 2021-06-22, H.J. Lu wrote: >On Mon, Jun 21, 2021 at 10:46 PM Fangrui Song wrote: >> >> On 2021-06-21, H.J. Lu wrote: >> >On Mon, Jun 21, 2021 at 9:16 PM Alan Modra wrote: >> >> >> >> On Mon, Jun 21, 2021 at 07:12:02PM -0700, H.J. Lu wrote: >> >> > On Mon, Jun 21, 2021 at 5:06 PM Alan Modra wrote: >> >> > > >> >> > > On Mon, Jun 21, 2021 at 03:34:38PM -0700, Fangrui Song wrote: >> >> > > > clang -fno-pic -fno-direct-access-extern-data works with clang>=12.0.0 today. >> >> > > >> >> > > -fno-direct-access-extern-data or variations on that also seem good to >> >> > > me. -fpic-extern would also work. I liked -fprotected-abi because >> >> > > it shows the intent of correcting abi issues related to protected >> >> > > visibility. (Yes, it affects code for all undefined symbols because >> >> > > the compiler clearly isn't seeing the entire program if there are >> >> > > undefined symbols.) >> >> > >> >> > I need an option which can be turned on and off. How about >> >> > -fextern-access=direct and -fextern-access=indirect? It will cover >> >> > both data and function? >> >> -fno-direct-access-external-data and -fdirect-access-external-data can turn on/off the bit. >> >> clang -fno-pic -fno-direct-access-external-data works for x86-64 and aarch64. >> >> We can add a -fno-direct-access-external > >Since both clang and GCC will add a new option for both data and function >symbols, can we have an agreement on the new option name? I am listing >options here: > >1. -fdirect-access-external/-fno-direct-access-external >2. -fdirect-extern-access/-fno-direct-exern-access >3. -fdirect-external-access/-fno-direct-exernal-access >4. -fextern-access=direct/-fextern-access=indirect >5. -fexternal-access=direct/-fexternal-access=indirect > >My order of preferences are 4, 5, 2, 3, 1. Preferring "extern" to "external" looks fine to me. (`extern` is the C/C++ construct anyway and this option describes what to do with default visibility non-definition `extern int xxx`/`extern void foo()`). -fextern-access=direct/-fextern-access=indirect and -fdirect-extern-access/-fno-direct-exern-access look good to me. I am happy to add aliases to clang if consensus is moving toward -fextern-access=indirect or -fno-direct-extern-access. >> >> Yes, FWIW that option name for gcc also looks good to me. >> > >> >I will change the gcc option to >> > >> >-fextern-access=direct >> >-fextern-access=indirect >> > >> >and change GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION >> >to GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS >> >> Note that this will be a glibc + GNU ld specific thing. >> >> gold and ld.lld error for copy relocations on protected data symbols by default. > >At run-time, there will be a mixture of components built with different tools >over time. A marker will help glibc to avoid potential run-time failures due >to binary incompatibility. glibc can perform the check without a GNU PROPERTY. For a st_value!=0 && st_shndx==0 symbol lookup during relocation processing, if the definition is found protected in a shared object, ld.so can report an error and make a suggestion like "consider recompiling the executable with -fno-direct-extern-access or -fpie/-fpic" I echo Michael's question in another thread https://sourceware.org/pipermail/binutils/2021-June/117137.html "IOW: which scenario do you want to not error on when you want to make the error conditional?" For such rare cases, we can use a LD_* environment variable. >> >> Now as to the need for a corresponding linker option, I'm of the >> >> opinion that it is ideal for the linker to be able to cope without >> >> needing special options. Can you show me a set of object files (or >> >> just describe them) where ld cannot deduce from relocations and >> >> dynamic symbols what dynbss copies, plt stubs, and dynamic relocations >> >> are needed? I'm fairly sure I manage to do that for powerpc. >> >> >> >> Note that I'm not against a new option to force the linker to go >> >> against what it would do based on input object files (perhaps >> > >> >I'd like to turn it on in linker without any compiler changes, especially >> >when building shared libraries, kind of a subset of -Bsymbolic. >> > >> >> reporting errors), but don't think we should have a new option without >> >> some effort being made to see whether we really need it. >> > >> >Here is a glibc patch to use both linker options on some testcases: >> > >> >https://sourceware.org/pipermail/libc-alpha/2021-June/127770.html >> > >> >> > > The main thing that struck me about -fsingle-global-definition is that >> >> > > the option doesn't do what it says. You can still have multiple >> >> > > global definitions of a given symbol, one in the executable and one in >> >> > > each of the shared libraries making up the complete program. Which of >> >> > > course is no different to code without -fsingle-global-definition. >> >> > >> >> > >> >> > -- >> >> > H.J. >> >> >> >> -- >> >> Alan Modra >> >> Australia Development Lab, IBM >> > >> > >> > >> >-- >> >H.J. > > > >-- >H.J.