From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by sourceware.org (Postfix) with ESMTPS id 15DC4386186E; Thu, 21 Jan 2021 21:42:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 15DC4386186E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=emacsray@gmail.com Received: by mail-pg1-f176.google.com with SMTP id v19so2218364pgj.12; Thu, 21 Jan 2021 13:42:45 -0800 (PST) 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=C3r0GzfjUGr3TJ8HYEYi9RXC2GhYmaPdns+qqu5uytE=; b=ihZc5oNEZ9Z9+/ZNA4cnyeQzFwljAuTxbt+R+55+4rQGKO3kJ4X2Iu5xlvxPpO+fAg g+K4+vmdsfO/oCuu1oSKIOTM4kEBX3wZ6LDJpuNenQDjQcOjV0jbBnM1u7/DEx9N2jdL ndaHAb1IRcsIZkKYoKfnpoYJb4Q54qBy4txRrFCCs9w8Nl8TB+P5CHQ0iK8EvT1dVv4f jYRytAQTjnPtMf2mKRDSI15M/ETPiJBHJ0Bhvm3A/hztwUO1CiLTVcLszSmqAJNxtBpN 8QadSxniQ4zzlA7gxnF02CjrjiBRA2sxW6srdg0AaMtMei2f3o/LHK5jHLOyjvdhsS6p ITeg== X-Gm-Message-State: AOAM531VtPfVZEUicoAYay6sjTmPCtvlBVrgDpliNdRTHqCF99EY5m5J 59nr39BYa1Q3NBesxeEQC1ZKWbRtFWzxSQ== X-Google-Smtp-Source: ABdhPJzPxQ4y3nVhntoywhpuRceutHnSh/IeLH2RvU+VPDmaRX4Y9qmMCyLNoa5ZP/1fhtUwqJ1uKg== X-Received: by 2002:a05:6a00:16c7:b029:1b6:68a6:985a with SMTP id l7-20020a056a0016c7b02901b668a6985amr1392237pfc.44.1611265364189; Thu, 21 Jan 2021 13:42:44 -0800 (PST) Received: from localhost ([2601:647:4b01:ae80:d89c:baec:d4bf:12f8]) by smtp.gmail.com with ESMTPSA id u12sm6090965pgi.91.2021.01.21.13.42.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jan 2021 13:42:43 -0800 (PST) Date: Thu, 21 Jan 2021 13:42:42 -0800 From: Fangrui Song To: "H.J. Lu" Cc: GNU gABI gnu-gabi , GCC Development , Binutils , GNU C Library , llvm-dev@lists.llvm.org Subject: Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX Message-ID: <20210121214242.3ha7fiecfbohxgyd@gmail.com> References: 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.6 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_H2, 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: 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, 21 Jan 2021 21:42:48 -0000 On 2021-01-21, H.J. Lu via Gnu-gabi 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. >> >> 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. > >-- >H.J. Hi, H.J. Thank you for CCing llvm-dev:) In the past various GNU ABI proposals went unnoticed by LLVM folks who don't happen to subscribe to GNU lists. (A lot! I personally subscribe to some lists and check the discussion just in case I miss something important:) ) I have researched a bit and observed that the following GNU_PROPERTY values are currently used by compilers/linkers: Bitwise OR for relocatable links. Bitwise AND for executable/shared object links. * GNU_PROPERTY_X86_FEATURE_1_AND = GNU_PROPERTY_X86_UINT32_AND_LO + 0, * used by Intel Indirect branch tracking and Shadow Stack * GNU_PROPERTY_AARCH64_FEATURE_1_AND, used by AArch64 Branch Target * Identification and Pointer Authentication Bitwise OR for all links. * GNU_PROPERTY_X86_ISA_1_NEEDED = GNU_PROPERTY_X86_UINT32_OR_LO + 2, * used by GCC -mneeded (for -march=x86-64-v[234]) There appear to be another type of AND/OR bits which are not defined in ABIs (AFAICT): * GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + 2 * GNU_PROPERTY_X86_FEATURE_2_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + * 1 I think generalizing the AND/OR idea to all architectures probably requires us to think about these questions: * What's the impending usage of the generic AND/OR ranges? ifunc? :) * Does the concept generalize well to other architectures? If we * consider AArch64/x86 FEATURE_1_AND to be the same thing, the current * usage is purely x86 specific. * Is AND/OR encoding expressive enough to represent the required states? * I've asked two folks and they expressed concerns. I think the three * AND/OR usage above speak for themselves. * Szabolcs Nagy mentioned that GNU_PROPERTY is an OS-specific mechanism * (GNU), but the features are oftentimes arch specific which make sense * to other OSes or bare-metal. * Szabolcs: Do we need any versioning mechanism? The feature selection and compatibility checking mechanism has some overlap with GNU/arch-specific attributes (e.g .ARM.attributes, .riscv.attributes). If I understand correctly, GNU_PROPERTY has an associated program header so it can be checked by loaders (kernel/ld.so/emulator) while Attributes don't have program headers so they are largely assembler/linker protocols. In an inflexible way that such feature bits can affect observable states to loaders as well, e.g. .ARM.attributes can affect e_flags (soft/hard float). .MIPS.abiflags has an associated program header PT_MIPS_ABIFLAGS (I know nearly nothing about mips) Some thoughts from mips folks would be useful. Last, I think a feature selection and compatibility checking mechanism is assuredly useful, but whether the current AND/OR scheme can perfectly satisfy that goal I am unsure. Having the proposal is a very good start, though:) Thanks a lot for driving the discussion:)