From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51599 invoked by alias); 13 Dec 2017 13:57:30 -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 51586 invoked by uid 89); 13 Dec 2017 13:57:29 -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=gb 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; Wed, 13 Dec 2017 13:57:27 +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 5D69E30008A4; Wed, 13 Dec 2017 14:57:25 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 34E564043882; Wed, 13 Dec 2017 14:57:25 +0100 (CET) Message-ID: <1513173445.15696.62.camel@klomp.org> Subject: Re: What integer type should ELF note header have? From: Mark Wielaard To: "H.J. Lu" Cc: Generic System V Application Binary Interface , Suprateeka R Hegde , Cary Coutant , Mark Mentovai , 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> 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/msg00018.txt.bz2 On Mon, 2017-12-11 at 04:11 -0800, H.J. Lu wrote: > Changing ELF64_Nhdr is going to be hard, but not impossible.=C2=A0=C2=A0In > theory, an 64-bit object may have a note entry which is bigger than 4 > GB.=C2=A0=C2=A0We can add a new note header: >=20 > typedef struct > { > =C2=A0 Elf64_Xword 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/* Length of= the note's name.=C2=A0=C2=A0*/ > =C2=A0 Elf64_Xword 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=A0=C2=A0=C2=A0/* Length of= the note's descriptor.=C2=A0=C2=A0*/ > =C2=A0 Elf64_Xword n_type;=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= /* Type of the note.=C2=A0=C2=A0*/ > } Elf64_Nhdr64; >=20 > Note segments/sections with 8 byte alignment should use Elf64_Nhdr64. > If we want to do it, we should do it now before > NT_GNU_PROPERTY_TYPE_0 > notes with the existing Elf64_Nhdr are generated by GCC 8 with > -fcf-protection -mcet. Yes, I think having a new note type is the way to go, if we want to change the alignment requirements. BTW. What is the reason you need 8 byte aligned notes? One issue we had with ELF notes for systemtap (the stap sdt notes) was that tools like prelink don't know about addresses inside notes. So we did end up with (also) using a .stapsdt.base section so we had a sh_addr that we could compare against in case tools like prelink needed to adjust needed to do address adjustments. Another thing about ELF notes is that they normally should be fairly small because when generating separate .debug files they get copied. So they take up space in both the main and debug file. So maybe using a normal ELF section might be an alternative? > I have updated glibc and binutils to support 4 byte and 8 byte alignments > in 64-bit objects by checking p_align/sh_addralign, instead of assuming > 4 byte alignment, like I looked at those glibc and binutils patch proposals and I must say I don't get the feeling you really got consensus on them. For both reviewers said that on GNU/Linux note alignment doesn't follow gabi and seemed to think it was a bad idea to change that now. I am somewhat surprised you committed them anyway without more discussion to get consensus. > > 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. > >=20 > These can be easily fixed with [...] But the issue is that the code is not wrong. ELF Notes on GNU/Linux always have had a fixed 4 byte alignment. That might not be what gabi intended, but it is what several code bases have been assuming for decades. If we are going to change that, it really should require new=20 ELF note types so consumers current code for existing notes isn't broken. Cheers, Mark