This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Change PCH "checksum"


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 <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]