From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 886A5385802E for ; Mon, 21 Jun 2021 22:50:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 886A5385802E Received: by mail-pj1-x1030.google.com with SMTP id g24so10835740pji.4 for ; Mon, 21 Jun 2021 15:50:35 -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=wdi3CbDdhrA75cH5ePsC9KuqtYr7SPjQ1DqIL6j2kfk=; b=k7tRUyW0JTBEWjqx3U1yl1tv9/uvK+3nbO9bzlW/hN02Ur9ghRFD5WrSqydekPupYp b6aFrnAkkuPBvoJDrr1gXoljfDidexO0Uvs5MHaJLrZ5SvWoLl+wM3mg8HagWTATKjp/ MABI20AMDabBjHbRlO18PH6Jmo+1+mKoajqtF5ROpaN6p7V1+jVg2SBN/ITafKvhB2qH AzCZ7VWu+COXPVxAV3z6+x8wbvtQP9V8/1KlEOzk0Vw15ra+r50UgZ/jj8Grji59X3n8 q2NPMsniatNwZcYdWsNlDuwwy2P2+yOjndNOUxJoxI6eL2cYu/N2KUPtE4hJjJEMvW4v iD+w== X-Gm-Message-State: AOAM530jpKwyDWD+uMJCzZ42F0K2O+pjcV9Y9LJ56YG134DYlz36W8Ei qEmVFBIjlkFkO7hhLvuDqQauU9DntVpu0KofQNA= X-Google-Smtp-Source: ABdhPJztDBFCVbK4+npVeF2ZhfSy1x0/qJznVLzwFUntefnCXFiKzqumZP60/1ST0KjpOOcVF2x4SVAUaMuuF+TKZlI= X-Received: by 2002:a17:90a:8a95:: with SMTP id x21mr398306pjn.154.1624315834665; Mon, 21 Jun 2021 15:50:34 -0700 (PDT) MIME-Version: 1.0 References: <20210620225029.390239-1-hjl.tools@gmail.com> <20210620225029.390239-3-hjl.tools@gmail.com> <20210621223438.efryfvivh2lrzcep@gmail.com> In-Reply-To: <20210621223438.efryfvivh2lrzcep@gmail.com> From: "H.J. Lu" Date: Mon, 21 Jun 2021 15:49:58 -0700 Message-ID: Subject: Re: [PATCH 2/2] elf: Add GNU_PROPERTY_1_NEEDED check To: Fangrui Song 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.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, 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: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 22:50:37 -0000 On Mon, Jun 21, 2021 at 3:34 PM Fangrui Song wrote: > > On 2021-06-21, H.J. Lu via Binutils wrote: > >On Mon, Jun 21, 2021 at 6:59 AM H.J. Lu wrote: > >> > >> On Mon, Jun 21, 2021 at 6:50 AM Alan Modra wrote: > >> > > >> > On Mon, Jun 21, 2021 at 05:42:06AM -0700, H.J. Lu wrote: > >> > > On Mon, Jun 21, 2021 at 3:46 AM Alan Modra wrote: > >> > > > > >> > > > I'm happy with the direction of this patch series, but do consult with > >> > > > ARM maintainers before committing. > >> > > > >> > > Nick, Richard, what do you think? > >> > > > >> > > > On Sun, Jun 20, 2021 at 03:50:29PM -0700, H.J. Lu via Binutils wrote: > >> > > > > If GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION is set on any input > >> > > > > relocatable files: > >> > > > > > >> > > > > 1. Don't generate copy relocations. > >> > > > > 2. Turn off extern_protected_data. > >> > > > > 3. Treate reference to protected symbols with single global definition > >> > > > > as local. > >> > > > > 4. Set GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION on output. > >> > > > > 5. Add -z [no]single-global-definition to control single global definition. > >> > > > > >> > > > This doesn't seem a good name. I think the name should have > >> > > > "protected" in it somewhere, since what you are doing here affects the > >> > > > way the x86 and arm toolchains treat protected visibility symbols. > >> > > > >> > > Removing copy relocation and canonical function pointers do help > >> > > protected symbols in shared libraries. > >> > > >> > Right. > >> > > >> > > But their impacts on executable > >> > > are unrelated to protected symbols. > >> > > >> > Obviously you do need some option to control code generated by gcc > >> > (and the gcc option name also doesn't seem right to me). I understand > >> > what you're trying to say in the name but it won't convey much to > >> > users. > >> > > >> > > Do you have any suggestions? > >> > > >> > Perhaps -fprotected-abi=nocopy and -fprotected-abi=copy for the gcc > >> > options? Or just -fprotected-abi and -fprotected-abi=copy. Saying > >> > with the first that code is respecting the ELF gABI, while with the > >> > second you're being tricky with dynbss copies and copy relocations. > >> > >> This also impacts function pointers. "copy" doesn't cover it. Florian > >> also points out that we need a different behavior in executable. Since > >> linker has all information, it may be able to set/clear the bit properly > >> based on input relocations. > > > >How about > > > >-fprotected-abi=extern > >-fprotected-abi=extern-data > >-fprotected-abi=extern-function > >-fprotected-abi=local > >-fprotected-abi=local-data > >-fprotected-abi=local-function > > I don't think the option name needs to mention "protected". > > First, -fpie and -fpic use GOT for external data/function today, no need > for a new option. > > The option is used with -fno-pic to prevent interaction issues with > protected definitions in shared objects, but the option itself doesn't > do anything with protected. For instance, the option can fix the pointer > equality issue with a -Bsymbolic or --dynamic-list linked shared object as well. > So I don't think the option name needs to mention "protected". It sounds reasonable. > clang -fno-pic -fno-direct-access-extern-data works with clang>=12.0.0 today. > The GCC feature request is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112. > > When taking an external function address in -fno-pic code, I suggest > -fno-direct-access-extern-function > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593). Actually, for > many arches I suggest that we just use GOT by default, no need for a > toggle. > > For x86-64 -fpie, we should just apply > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html > I'd like to have a single option to use GOT to access external symbols and make protected symbols local. Programmer doesn't have to know if PIE is enabled by default nor if copy relocation is used by default. -fsingle-global-definition isn't a good name. But I can't find a better one. -- H.J.