From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 7B738383B835; Thu, 17 Jun 2021 19:46:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7B738383B835 Received: by mail-pl1-x631.google.com with SMTP id f10so1365907plg.0; Thu, 17 Jun 2021 12:46:31 -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=DjQL48HQGfIRzg2KYrjj5LKI7V0njJoifRCoPES6e6I=; b=aY40iT7wfjrBd0BP/P/0q/U4zg8Av89ZGhxo/jG++8WuCP2yrQdqrUJjcnBQT1GpUE S1vqLsG+4ObE8limc6C10vzKnyk5Dd51acE4YHPjG8cc3NRauht+KLVjZAceqxdaW5YJ VUCXUjCoMqNYZxKO2KmG5y9NBzsREwbhYBACG08UOXnTIhWfs5u4OsU/HI0/ZXhRU7hU ulx2/vsFfwLvQaf9qGEGVJY5p67/A3BuaI16ULByNfFFX8j8QIFZXrBqYzpEM9uyCwaC Ch5yX6r3l+OPHf1/b7UFrWSU0J9GkxnS9e8FnDhA13EMYYaP2g9Fs4YZaeqs0Xo1Yt+O tv0Q== X-Gm-Message-State: AOAM5305XNwxfUnpqWEKYyr4j46I9Cf09rnDEVaSYqO6+cYyOSrV/y8Y tKNQi6AyW+eGIis//7LZFgGgfaiVTLgEuMyEK1A= X-Google-Smtp-Source: ABdhPJyHGE1bp8aW0mij/Jn21BzFYtPk9tO1cie9MmL5EgQKFctad4zw9WUOh1bgsI/bIY7mbUP92YNlL9r7vXk+6wQ= X-Received: by 2002:a17:90b:10e:: with SMTP id p14mr942671pjz.153.1623959190621; Thu, 17 Jun 2021 12:46:30 -0700 (PDT) MIME-Version: 1.0 References: <20210617193825.zzjyoybttajksw5x@google.com> In-Reply-To: <20210617193825.zzjyoybttajksw5x@google.com> From: "H.J. Lu" Date: Thu, 17 Jun 2021 12:45:54 -0700 Message-ID: Subject: Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX To: Fangrui Song Cc: GNU gABI gnu-gabi , GCC Development , Binutils , GNU C Library , llvm-dev@lists.llvm.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3025.7 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: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 19:46:33 -0000 On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song wrote: > > On 2021-06-17, H.J. Lu via llvm-dev wrote: > >On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu wrote: > >> > >> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote: > >> > > >> > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > >> > > >> > #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 > >> > #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > >> > > >> > A bit in the output pr_data field is set only if it is set in all > >> > relocatable input pr_data fields. If all bits in the the output > >> > pr_data field are zero, this property should be removed from output. > >> > > >> > If the bit is 1, all input relocatables have the feature. If the > >> > bit is 0 or the property is missing, the info is unknown. > > How to use AND in practice? > Are you going to add .note.gnu.property to all of crt1.o crti.o > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object > files written in assembly? > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI > >> > > >> > #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 > >> > #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff > >> > > >> > A bit in the output pr_data field is set if it is set in any > >> > relocatable input pr_data fields. If all bits in the the output > >> > pr_data field are zero, this property should be removed from output. > >> > > >> > If the bit is 1, some input relocatables have the feature. If the > >> > bit is 0 or the property is missing, the info is unknown. > >> > > >> > The PDF is at > >> > > >> > https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf > >> > > >> > -- > >> > H.J. > >> > >> Here is the binutils patch to implement it. > >> > > > >If there are no objections, I will check it in tomorrow. > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be > very kind of you if you can collect more use cases before generalizing > this into a non-arch-specific GNU PROPERTY. > > The "copy relocations on protected data symbols" thing is x86 specific > and only applies with gcc+GNU ld+glibc. > Non-x86 architectures don't have this thing. > gold doesn't have this thing. > clang doesn't have this thing. It will be used to remove copy relocation and implement canonical function pointers, which will benefit protected data and function. -- H.J.