From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121114 invoked by alias); 13 Dec 2018 13:02:58 -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 121080 invoked by uid 89); 13 Dec 2018 13:02:57 -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=ccoutantgmailcom, ccoutant@gmail.com, H*i:CAJimCsFWo, H*i:sk:j0PbK_B 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-ot1-f53.google.com Received: from mail-ot1-f53.google.com (HELO mail-ot1-f53.google.com) (209.85.210.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Dec 2018 13:02:56 +0000 Received: by mail-ot1-f53.google.com with SMTP id u16so1789999otk.8; Thu, 13 Dec 2018 05:02:55 -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=Gc/9V1dylo9sCUjHJ3BIO85xUqnEnuhK+FxGFhrpUpA=; b=iDyYqiBZnzO4oHqqdSNjCyDu9HNKYRKem3EHwhbS8gEHl1fP0LNQC7s0dbEZAA7dpa PWO5K0IUJaT28IJRjOkIFZ3g62UxPwL/ovPkhR2nhWO+dr6Wq6aMmA8XTW+4bnPjGExz qXlpthceCAKMHICsB3LaUoARBjgAYBnAXdqB4+RrSDUWAitqdAnElnAclvLyOZYeJyvG fkoaNPugo62ODxNz7b4hJc2CvKhw8Cm1k3KR/r0ZDarUqSiYmLAbskGp5FvcTzIOlR+B JxbPSckOmoalbKDR6wxgYjuoLecp92oXBt+Q2OPAijMH5sDezaIe/SDFLF7+D5pPT0JW 1ZvQ== 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=Gc/9V1dylo9sCUjHJ3BIO85xUqnEnuhK+FxGFhrpUpA=; b=JBlw3bzgSO3VrhH09atv7eFX9rRAHuIM19fBoMEYmuOxAHuvTasOQUaHWEi5BRJlz0 cnkXQRjJl6PKh2d1wmIy1ABiuIlFpAq/nQEe2ZbsIHFV4PaNYe2HKFpe5Tc1V1nqjeXH ORXvm6vyYHcxBjo0BMyZM0rtTPvE1vmc0xWIdNXQe3m4etO8HpLl5xtAtIXE443ECJZ5 YD+wroWEwdkjGWUnF11cl0SF/AOGJhOb+iZi6dlRY7vHZp8u/k+1lRUztrPqucmrMxf5 RVj2wYIZWEe1YujMFATuMlfYGHR2WEwW2tG+vzJJpu+3f+YUKqRishxBVpJspYCNZWK5 +QEA== X-Gm-Message-State: AA+aEWaH0jAbXMENUiUIiPg6AoAPKkGqWZQJGY2sDPrQqpqVY/I2T51n yK5/B7ze4XMCNnI+mm1cZtQDUAkcs0iJ4cJE13B+lL7n X-Google-Smtp-Source: AFSGD/U7OyKwURdTnEUyyMo5tikMIsadq+SLOS4+ADq+aA+vwsKA5quYcrAPhqZwiFNRTx4+v+Ha0WYDKK/3eQ2fTGQ= X-Received: by 2002:a9d:65ca:: with SMTP id z10mr17944176oth.4.1544706174378; Thu, 13 Dec 2018 05:02:54 -0800 (PST) MIME-Version: 1.0 References: <87k1kyhbki.fsf@oldenburg.str.redhat.com> <87zhtcz7cg.fsf@oldenburg2.str.redhat.com> <20181211131933.GA9599@gmail.com> <20181212104449.GB62340@wildebeest.org> In-Reply-To: From: "H.J. Lu" Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Add PT_GNU_PROPERTY to cover .note.gnu.property section To: Cary Coutant Cc: Mark Wielaard , Florian Weimer , Binutils , GNU C Library , gnu-gabi@sourceware.org, x86-64-abi Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00037.txt.bz2 On Wed, Dec 12, 2018 at 8:12 AM Cary Coutant wrote: > > > > > As you might expect, I support this new program header. Ideally, I'd > > > > have liked to replace the input SHT_NOTE sections with > > > > SHT_GNU_PROPERTY sections and dispense with all the note section > > > > overhead, but I'll take this as a compromise. > > > > > > Why can't we switch to SHT_GNU_PROPERTY? My fear with combining > > > PT_GNU_PROPERTY with SHT_NOTE is that it will be even more confusing > > > > There is no requirement for PT_XXX to have SHT_XXX, like PT_GNU_RELRO. > > But it is not normal for the linker to perform such special processing > on an SHT_NOTE section. When a section requires special processing, it > is customary to use a new section type. Otherwise, the linker has to > resort to string matching on the section name. Section names in ELF > are not supposed to have special meaning to the linker. Good point. It is too late now. > > > Also I thought there was still a question whether any or all > > > newly proposed property features and flags are actually needed > > > as loadable segments. There is a clear overlap with the GNU > > > Attributes (which are non-loadable). I would like to see consensus > > > first on the new property format/flags and which are and which > > > aren't needed as loadable properties at runtime. > > > > Yes, they are needed in loadable segment. That is the main motivation > > for GNU program property, > > The only properties required in a loadable segment are those that will > be used by the loader. From what I can tell so far, the USED bits > can't be used by the loader, so why can't they go in the GNU > attributes section? There are couple reasons: 1. GNU attributes section has a very different format and isn't designed for loader. 2. X86 needs loadable properties. 3. X86 should use a uniform format for all properties. 4. USED bits can be useful. For example, if AVX512 isn't marked as USED, OS loader may optimize OS for this process with this info. -- H.J.