From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86864 invoked by alias); 12 Dec 2018 16:12:27 -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 86834 invoked by uid 89); 12 Dec 2018 16:12:26 -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=customary 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-it1-f194.google.com Received: from mail-it1-f194.google.com (HELO mail-it1-f194.google.com) (209.85.166.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Dec 2018 16:12:25 +0000 Received: by mail-it1-f194.google.com with SMTP id o19so9800371itg.5; Wed, 12 Dec 2018 08:12:24 -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=YstNUB4wvaOq85MFsmuXymVngRQ5AZDQH1B8hR7E9n4=; b=PdDaKQ0EvYjvy2nVESNcr8PD6GDcTWpl2xdiIwKSbaCKT5wtzJwT0wdSKdyJ/ZCExk kHgCQL6QBpBItb9GqX31/2nmsY8bh82T8RDIVwWypgh9AHLABCav/mChl4Wg04sjkXsc ZSgk+f8vvzOuZRhJEo8ID3MUqBZEecSpAZ4he3D4XsSU40JzTnOJeI+bQy88xiv8T6aB ShwIyHRJ0/okWGYEs9aGKsos4rCUlTsBbcyE43Jt3yA7WODJ9dWXfuRV2lYkkv7z4AS4 GSrr7kFcoXHaaGumgGx1d289wotVbUguo3gpkbHu/c045lAJuYlGOM2dI/RE9wv/5o+f /wQw== 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=YstNUB4wvaOq85MFsmuXymVngRQ5AZDQH1B8hR7E9n4=; b=namOCGkhhxyoJtmqTtbPPhaeyciYXiL0U6P44uX9HqGxSjOvUWChw42UQy2Nh5db5z kKziheDuEcz/9Sg8RPYL227ny0CbTd7MUTdNUvN4qH4orz6adA0B5MVLyyuxhpk01E+7 A5j61qGqqnmYsWKmdo7sUCF3/eirTscDyrqzfWwkgEVWMx4wCPUW4C9t224i5hesiC95 wUZs3kGVd0VkFk+uoIH5M6u41iKG1kdBQa3lAwktLeWuGvRiMqUZq/TSQ2ofURcd/QNL FtT3Hkt8uemNRDch4Vx2vxOhPjaw4Tnp81/knBOrtGTRiwfhrdy3rAQ/CYLqfa7SNJoP c7fQ== X-Gm-Message-State: AA+aEWaUYa8V7cmyzuXOiW6RWv/mjXo6NEfhj4Pctg/KiYgw8zf9HxTZ adZR+lm+pUrJjWKyr2yYPkVEmIZfXwRpp/1k6nw= X-Google-Smtp-Source: AFSGD/W67nIGh3pAaB27UvjSAkatf0/v1tr4gw+zG6Y4muEAefFAuvRHs28wu6PpsqPWavyMLu6nVZcDmMgfrDCWSWg= X-Received: by 2002:a05:660c:4c5:: with SMTP id v5mr6668507itk.104.1544631143331; Wed, 12 Dec 2018 08:12:23 -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: Cary Coutant 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: "H.J. Lu" 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/msg00036.txt.bz2 > > > 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. > > 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? -cary