From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115282 invoked by alias); 11 Dec 2017 09:43:13 -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 114927 invoked by uid 89); 11 Dec 2017 09:43:13 -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=pays, HTo:U*mark, our 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; Mon, 11 Dec 2017 09:43:11 +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 8A4A632B90ED; Mon, 11 Dec 2017 10:43:09 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 4AC5C4000F04; Mon, 11 Dec 2017 10:43:09 +0100 (CET) Message-ID: <1512985389.15696.45.camel@klomp.org> Subject: Re: What integer type should ELF note header have? From: Mark Wielaard To: generic-abi@googlegroups.com, hegdesmailbox@gmail.com, Cary Coutant , "H.J. Lu" , Mark Mentovai 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> 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/msg00012.txt.bz2 On Sun, 2017-12-10 at 22:22 -0700, Ali Bahrami wrote: > To my reading, the words of the gABI support what HP-UX did, and the > comment in the Solaris code makes me think our definition of > ELF64_Nhdr > was a mistake. And given that the rest of us don't have any installed > base (yet) of 8 byte alignment notes, it seems that the most > compatible > thing that we could do would be to also use 8-byte words for these > fields. > triggered by an sh_addralign, or p_align, of 8. That seems to match > the > gABI words, and preserves interoperability with HP-UX. >=20 > An open question to you and Mark, and any others in the GNU world: > Would you consider making that change? If so, I think we (Solaris) > would have no problem in doing likewise. I am afraid changing ELF64_Nhdr/GElf_Nhdr now from 32bit Words, or changing the alignment of the namesz or descsz from 4 byte alignment is not going to work. It is too hardcoded in various GNU/Linux code bases now to change. On GNU/Linux ELF notes have been used a lot already, if only to parse the build-id embedded in every executable. So you will find a lot of code that will simply do: /* =C2=A0* Align offset to 4 bytes as needed for note name and descriptor data. =C2=A0*/ #define NOTE_ALIGN(n) (((n) + 3) & -4U) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0GElf_Nhdr *nhdr =3D ptr; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0size_t namesz =3D NOTE_ALIGN(nhdr->n_namesz), =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0descsz =3D N= OTE_ALIGN(nhdr->n_descsz); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0const char *name; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0ptr +=3D sizeof(*nhdr); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0name =3D ptr; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0ptr +=3D namesz; [...] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0ptr +=3D descsz; The above is from the linux kernel perf tool (tools/perf/util/symbol- elf.c), but I can easily find more examples of hard coded parsing of ELF notes that simply assumes they are 32 bit Words, 4 byte aligned (it is basically what elfutils libelf also does). You could play with the SHT_NOTE sh_align and PT_NOTE p_align values, but I haven't actually found any code that pays attention to it. So a lot of code would have to be rewritten. Cheers, Mark