From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33672 invoked by alias); 22 Dec 2017 22:54:20 -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 33659 invoked by uid 89); 22 Dec 2017 22:54:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=0148, U*mark, emails X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Dec 2017 22:54:16 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 7D018300090E; Fri, 22 Dec 2017 23:54:13 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 31009411B8BD; Fri, 22 Dec 2017 23:54:13 +0100 (CET) Message-ID: <1513983253.3236.38.camel@klomp.org> Subject: Re: What integer type should ELF note header have? From: Mark Wielaard To: generic-abi@googlegroups.com Cc: gnu-gabi@sourceware.org Date: Sun, 01 Jan 2017 00:00:00 -0000 In-Reply-To: References: <99c8440b-54d8-41bc-6e4d-cd1894536bb7@Oracle.COM> <993f8818-65a6-b83a-9d55-1fbbd88db8c8@gmail.com> <1512985389.15696.45.camel@klomp.org> <1513173445.15696.62.camel@klomp.org> <1513245995.15696.78.camel@klomp.org> <3704867e-58b8-3da1-2b29-959ad67a540d@Oracle.COM> <1513355861.15696.95.camel@klomp.org> <1513941724.3236.32.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-SW-Source: 2017-q4/txt/msg00028.txt.bz2 Hi, Note that gnu-gabi drops HTML emails. Please use plain text. On Fri, 2017-12-22 at 03:49 -0800, H.J. Lu wrote: > On Dec 22, 2017 6:22 AM, "Mark Wielaard" wrote: > > It is not really OK. I have seen code that marks an ELF file as > > invalid and/or gives up processing ELF notes if it contains notes=20 > > that don't follow the standard 4-byte alignment/layout rules. > > So this really impacts any tool that processes any ELF note. >=20 > The unfixed tools won't be able to understand the property > note, one way or the other. The real question if all note consumers > should be updated to check the note alignment specified by > section/segment header. > When they are updated, what should they do > if they see 0,1,4,8 alignment? That is not the real question. Of course if you introduce a new note type or a new note section/segment type existing users need to be updated to take advantage of the new type. But you are proposing to stuff data into SHT_NOTE sections/PT_NOTE segments that cannot be parsed at all without changes. So to existing tools it is just an invalid ELF file with garbage data. That is the problem. The real question is why you need a new note data layout. If the answer to that is really that you cannot use the existing structure then the real question is where we are going to store your new data layout. It shouldn't go into a SHT_NOTE section or PT_NOTE segment, because that will break existing tools. But we could certainly introduce SHT_NOTE64 and PT_NOTE64 to store such new note types. > > The simplest really is to just use the normal note > > alignment/layout. This seems to be what Fedora rawhide toolchain > > currently does for NT_GNU_PROPERTY_TYPE_0. That way all tools can > > process the note and the only thing you need to be careful for is > > that some values in the note descriptor might not be naturally > > aligned. This really shouldn't be an issue, especially not if this > > is x86-only anyway. >=20 > The specification isn't x86 specific. What in the specification requires you to change the existing ELF note data layout? It seems the current layout as used in Fedora rawhide works just fine. You keep saying you like to have naturally aligned data in the note description. And I agree that would be a nice to have. But it seems hardly so important to break the current format. Cheers, Mark