From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121447 invoked by alias); 22 Dec 2017 11:22: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 121433 invoked by uid 89); 22 Dec 2017 11:22:20 -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=U*mark, season 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 11:22:13 +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 69714300090E; Fri, 22 Dec 2017 12:22:10 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id D60A14137270; Fri, 22 Dec 2017 12:22:04 +0100 (CET) Message-ID: <1513941724.3236.32.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> 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/msg00027.txt.bz2 On Fri, 2017-12-15 at 08:52 -0800, H.J. Lu wrote: > > On Fri, Dec 15, 2017 at 8:37 AM, Mark Wielaard wrote: > > But honestly it feels much cleaner to just leave this past mistake be. > > And maybe just introduce new notes types if people really care about > > having naturally aligned note data in 64-bit ELF files. >=20 > If NT_GNU_PROPERTY_TYPE_0 note is the only concern, I have > updated all of its REAL consumers to handle it properly.=C2=A0=C2=A0It is= OK if a tool > doesn't understand it. 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 that don't follow the standard 4-byte alignment/layout rules. So this really impacts any tool that processes any ELF note. > However, if we want to add SHT_NOTE64/PT_NOTE64, please do it ASAP > since NT_GNU_PROPERTY_TYPE_0 note is used for Intel CET. Yes, I think that is the correct long term solution. But we might not get consensus soon over the holiday season. So if you probably should do something that doesn't require introducing new note layout/alignment or new note section/phdr 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. If you insist on having the data value be naturally aligned for this one property then it might make sense to look if you can use an existing ELF construct that does give those guarantees. e.g. Use a special symbol, PT header or DT value to encode the property. Cheers, Mark