From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78192 invoked by alias); 27 Nov 2018 13:41:18 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 78156 invoked by uid 89); 27 Nov 2018 13:41:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:_u247Oj, H*i:sk:_u247Oj, ccoutant@gmail.com, ccoutantgmailcom X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 3 recipients X-HELO: mail-oi1-f172.google.com Received: from mail-oi1-f172.google.com (HELO mail-oi1-f172.google.com) (209.85.167.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Nov 2018 13:41:15 +0000 Received: by mail-oi1-f172.google.com with SMTP id c206so19315314oib.0; Tue, 27 Nov 2018 05:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NWx4eZugDJV6vSuHDH7lhYEQVqz+ZyX/qMuM/bZl+cQ=; b=KoxF1mAGNIrD04P2laqfUfWc/hKVuUG7Gi9O7+2Ye0QT/b7hA8JdwzHchByH/eDopY ilRpUjO2nxGypo8kCe/ejbjVcO56Zctsysak2vSMp4egNt+khuNcA72jw79vqbrtyuGd ygDdjgTlFGbe5fJIFMIPHtcM8io8n2mVfspQbrja21TIJMp/AoDAsd8P0A6enorK2+eS SIBdM8xF2aFWDngoDsJKBqejaPVL1u9TDsTIBBHEXNTYiIZ7o4y0RuM2W+szb1dDPENX P5QT9z/ekTjExKfJojjDu6fAHVjNvT5J3vYxwcDXam8irwumdhHLR0JJTfsDQnTRWPfY 9Bww== 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=NWx4eZugDJV6vSuHDH7lhYEQVqz+ZyX/qMuM/bZl+cQ=; b=pqEJUMRgIsou++qo/26dRjnhW0x4brxivXsJWWu2Qpfa92k64kFSM5ZdpJ3jI2z2SG s3ThMkuTuP8pKOpYbVhHeWymEn281a/TvyVVkRm3eqwHtTt75yrRDzJ+DG6JIuXvOQQ/ pm9pOqx8o8MDrSYBH2ODXWNpJ4rjxt+HOALyb7fy+YEEG/mRTpWTec34vkOSrT7H/q83 gm6SCTfY95V8VNcxkJQy1CW6R6Pm3ZSM/zPwzBEfUmXw+cZBP2Z/x9N8Nlhu2P0ZffDY wIw1aHoyuw1jkneuxBks0CvXVFQIF4e0esh3dwiYGmmLplHTwzccctdRhM6XrqWMRvZI B87w== X-Gm-Message-State: AGRZ1gLBoHuzvBYNao1BrvoWUkvV/JbNqDjQytkWZO1sRSm+xho6wbTU oXAsE/L4otT9kRi011zNFHI+qZmFVMW8qWQan2w= X-Google-Smtp-Source: AJdET5crIkjebiwuRPFki+jEy2u+nVjJB5RANIrfRhqr5sxOpRZLwKJqOcW2nzkaazA6t/i8Gn64M+quLRDZxt79/JM= X-Received: by 2002:aca:da0b:: with SMTP id r11-v6mr18754054oig.35.1543326073196; Tue, 27 Nov 2018 05:41:13 -0800 (PST) MIME-Version: 1.0 References: <87ftvoouda.fsf@oldenburg.str.redhat.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Linux gABI: Add a GNU_PROPERTY_BY_LINKER property To: Cary Coutant Cc: Florian Weimer , Binutils , GNU C Library , gnu-gabi@sourceware.org, x86-64-abi@googlegroups.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00021.txt.bz2 On Mon, Nov 26, 2018 at 2:34 PM Cary Coutant wrote: > > > > > GNU_PROPERTY_X86_UINT32_VALID was defined to address this issue such that > > > > linker sets the bit in values of x86 properties for non-relocatable > > > > outputs. But it isn't sufficient: > > > > > > > > 1. It doesn't cover generic properties. > > > > > > Okay. > > Does this imply that the property notes in all pre-existing binaries > can't be trusted? Loader needs to make extra effort to check if property notes are valid: https://sourceware.org/bugzilla/show_bug.cgi?id=23509 > > > > 2. When -mx86-used-note=yes is passed to x86 assembler, the > > > > GNU_PROPERTY_X86_UINT32_VALID bit is set in GNU_PROPERTY_X86_ISA_1_USED > > > > property in object file and linkers without GNU property support generate > > > > invalid NT_GNU_PROPERTY_TYPE_0 notes with the GNU_PROPERTY_X86_UINT32_VALID > > > > bit set. > > > > > > Surely this is a GAS bug? Why not fix that bug? > > > > Linker removes GNU_PROPERTY_X86_ISA_1_USED when its value is empty. > > Maybe linker shouldn't do that. > > Please explain how that answers Florian's question? You lost me. > > What exactly are you saying the linker should not do? In your Aug. 10 > proposal, ISA_1_USED is in the UINT32_OR_AND range, which specifically > says the bit should only be set in the output if *all* input files > contain the property (although it's unclear whether you meant "this > property is present in all relocatable input files" to mean a non-zero > property in all input files). No. A property can have zero bits. I updated my proposal to: 1. Add a GNU_PROPERTY_BY_LINKER property which should only be set by linker for non-relocatable outputs to indicate the property note is valid and generated by new linkers. Loaders can check this property to verify that the property note is valid. 2. Remove GNU_PROPERTY_X86_UINT32_VALID. > > > > 1. Add a GNU_PROPERTY_BY_LINKER property which should only be set by > > > > linker for non-relocatable outputs to indicate the property note is > > > > valid and generated by new linkers. Loaders can check this property > > > > to verify that the property note is valid. > > > > 2. Remove GNU_PROPERTY_X86_UINT32_VALID. > > > > 3. Define GNU_PROPERTY_X86_ISA_1_BASE for GNU_PROPERTY_X86_ISA_1_USED, > > > > which has the same bit as GNU_PROPERTY_X86_UINT32_VALID and use it > > > > for -mx86-used-note=yes with x86 assembler. > > > > > > The alternative approach would be to switch to a new PT_ segment for > > > this because those aren't included in relocatable objects. (Maybe it's > > > time for another approach.) > > > > PT_NOTE is used so that binaries with GNU properties are backward > > compatible with loaders which don't support GNU properties. They will > > run without any new features from GNU properties. > > With both your Aug. 10 proposal and this one, you're throwing > compatibility out the window by saying the loader shouldn't trust > those old notes without VALID bits. Can't we use this opportunity to This has been handled. > just do it right? At this point, I don't really care if you keep on > using SHT_NOTE for the properties in relocatable files, but please, > let's use a proper PT_GNU_PROPERTY segment for executables. (Sorry, I > promised to yield to the consensus, but the design keeps getting more > complicated.) > PT_GNU_PROPERTY isn't compatible with existing loaders. This needs to be both forward and backward compatible. -- H.J.