From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by sourceware.org (Postfix) with ESMTPS id 322223894C14; Tue, 22 Jun 2021 13:28:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 322223894C14 Received: by mail-pj1-x1031.google.com with SMTP id 13-20020a17090a08cdb029016eed209ca4so2268095pjn.1; Tue, 22 Jun 2021 06:28:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/VTj8pSXUKTqgAWGjcPk7kxRbPRG9co8yY4RGpP4Xyo=; b=oG2TQYzvdmxOe2gQkzaGwnFcFrgGqbTBNdcBEHKm6W65WvW+jQogDAyF/v+he7q8XS ZvJ7cK6xqhb27dBWfqxmfhhQNAT2nbdNF5X2pteKDZTHeNtvyhDDrhp9jw0RTK/vKnFf Cjt2BCr1orp2Y6G8EktHbsPMnDpMpMziJ5002PB7mPW34yH/fbFiMwdu/GhbeyPy+CUn ba39ieEK5frpvFTZfLyOz7t9o3rWg/n9vQwWenAiet4lKCPO1KEbBRbrHrBiNWANn4// Z//KJ37wJWObgCeJWZnUZkWReqgEZ8NeqAuP9/J/RiebHA8Ydc7o0b7WqXCMu9F3WoCJ i6ig== X-Gm-Message-State: AOAM533SJvu22nZwhDq2KT3t0s0voOCsloznG1v2ZP2ffqayMM4arbjg IEfN7VhvfCmguOgMxV6PMpJmIfwlJHALZr2QBX0= X-Google-Smtp-Source: ABdhPJxUrCU1TaH9oAmah6YImVAYx9js7rriSlBhnO35Gkx3osKRmehu9zlQ3VMa/SNRKo9iDbvf8EtDFKAEEaqtvs0= X-Received: by 2002:a17:90b:10e:: with SMTP id p14mr4063171pjz.153.1624368498246; Tue, 22 Jun 2021 06:28:18 -0700 (PDT) MIME-Version: 1.0 References: <20210621223438.efryfvivh2lrzcep@gmail.com> <20210622054639.gti363y2dqpjawaa@gmail.com> In-Reply-To: <20210622054639.gti363y2dqpjawaa@gmail.com> From: "H.J. Lu" Date: Tue, 22 Jun 2021 06:27:42 -0700 Message-ID: Subject: Re: [PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check To: Fangrui Song , GCC Patches Cc: Alan Modra , Florian Weimer , Richard Earnshaw , Binutils , hubicka@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3025.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 13:28:20 -0000 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. > >> 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. > >> 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.