From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96202 invoked by alias); 26 Feb 2019 17:13:40 -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 96183 invoked by uid 89); 26 Feb 2019 17:13: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=H*i:sk:02b4697, H*f:sk:02b4697, Hx-languages-length:3469, H*MI:sk:02b4697 X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Feb 2019 17:13:37 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 813ACAEA9; Tue, 26 Feb 2019 17:13:35 +0000 (UTC) Date: Tue, 26 Feb 2019 17:13:00 -0000 From: Richard Biener To: Mark Wielaard cc: gcc@gcc.gnu.org Subject: Re: [RFC] Change PCH "checksum" In-Reply-To: <02b469715bce6e99daf8cf2d1ee6811f2a9127b5.camel@klomp.org> Message-ID: References: <4b144c8b12b3413b1ec450d9ba468b71dd5b4547.camel@klomp.org> <02b469715bce6e99daf8cf2d1ee6811f2a9127b5.camel@klomp.org> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2019-02/txt/msg00152.txt.bz2 On Tue, 26 Feb 2019, Mark Wielaard wrote: > On Tue, 2019-02-26 at 15:36 +0100, Richard Biener wrote: > > On Tue, 26 Feb 2019, Mark Wielaard wrote: > > > > > 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 > > > > > > > > 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 ... :/). > > > > > > > > So - is merely changing the re-alignment from 4 to > > > > 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 = (p_align <= 4) ? 4 : 8; > > > offset += ALIGN ((ALIGN (sizeof (uint32_t) * 3 + namesz, align) > > > + descsz), align); > > > > That would mean when p_align == 8 the note name isn't 8-aligned > > but just 4-aligned? That is, sizeof (Elf*_Nhdr) == 12, and the > > name starts right after that instead of being aligned according > > to p_align? That sounds odd... So p_align only applies to > > the descriptor? > > Yes, it is that odd. There are 3 kinds of ELF notes. > > The traditional ones as used by GNU and Solaris, which use 4 byte words > for everything whether in ELFCLASS32 or ELFCLASS64 and which are 4 byte > aligned themselves. > > The gabi ones, which are similar for ELFCLASS32 but for ELFCLASS64 all > words are 8 bytes and 8 bytes aligned themselves (as used by HPUX). > > And the new style GNU Property notes, only used in ELFCLASS64, which > use 4 byte words for the first 3 fields, immediately followed by the > name bytes, padded so that desc is 8 bytes aligned and the note as a > whole is 8 byte aligned. I wonder how to distinguish the latter two - does one really need to test the size of ElfW(Nhdr).n_namesz for example? Why was the GNU Property one chosen this way?! Is the first case (traditional GNU note) with p_align == 8 invalid? That is, is testing p_align really the correct way to determine how the individual parts are aligned? I guess not. So - how do I identify a GNU Property note vs. a traditional note vs. a gabi one? Why was the third one added?! (I guess I asked that already...) Richard. > Cheers, > > Mark > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)