From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15983 invoked by alias); 26 Feb 2019 11:40:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 15973 invoked by uid 89); 26 Feb 2019 11:40:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1523 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; Tue, 26 Feb 2019 11:40:37 +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 5606530007B4; Tue, 26 Feb 2019 12:40:34 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 0885740006DD; Tue, 26 Feb 2019 12:40:34 +0100 (CET) Message-ID: Subject: Re: [RFC] Change PCH "checksum" From: Mark Wielaard To: Richard Biener Cc: gcc@gcc.gnu.org Date: Tue, 26 Feb 2019 11:40:00 -0000 In-Reply-To: References: <4b144c8b12b3413b1ec450d9ba468b71dd5b4547.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-SW-Source: 2019-02/txt/msg00146.txt.bz2 On Tue, 2019-02-26 at 09:33 +0100, Richard Biener wrote: > On Mon, 25 Feb 2019, Mark Wielaard wrote: > > Since the introduction of GNU Property notes this is (sadly) no > > longer > > the correct way to iterate through ELF notes. The padding of names > > and > > desc might now depend on the alignment of the PT_NOTE segment. > > https://sourceware.org/ml/binutils/2018-09/msg00359.html >=20 > Ick, that's of course worse ;) So it's not entirely clear what > the correct thing to do is - from how I read the mail at the above > link only iff sh_align of the note section is exactly 8 the above > ALIGN would use 8 byte alignment and else 4 is correct (independent > on sh_align). Or can I assume sh_align of the note section is > "correct" for all existing binaries? Note also the eventual > difference > between note sections and note program headers which have another, > possibly different(?) alignment? It's of course "easy" to replace > 4 above by info->dlpi_phdr[i].p_align (but the align field differs > in width between elfclass 32 and 64 ... :/). >=20 > So - is merely changing the re-alignment from 4 to=20 > info->dlpi_phdr[i].p_align "correct"? Yes, you will have multiple note segments one that combines the 4 padded notes and one that combines the 8 padded notes. Some tools put 0 or 1 in the align field, so you might want to use (completely untested): align =3D (p_align <=3D 4) ? 4 : 8; offset +=3D ALIGN ((ALIGN (sizeof (uint32_t) * 3 + namesz, align) + descsz), align); Cheers, Mark