[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282

["rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #13 from rguenth at gcc dot gnu dot org  2010-01-17 15:54 -------
(In reply to comment #12)
> (In reply to comment #4)
> > The patch is not yet in but I think it's the wrong approach.  Instead
> > uncompression should deal with tail padding.
> 
> I think you're right.  I just ran into this bug on cygwin (x86/PE-COFF) because
> section sizes were being padded to meet the alignment requirements, rather than
> leaving unallocated gaps between them.  A neat solution would be to use
> pkcs-style self-describing padding at the end of each section: you always add
> at least one byte of tail padding (even if that means adding a whole
> alignment-size word), and you put that number of bytes of padding in the final
> pad byte.  It would mean bumping the lto header version and watching out for
> back-compat of course.

Maybe.  Or simply store the size of the compressed blob at the beginning?
(Not that I have spent too much time with looking how zlib works)

> Apropos this particular patch, I see you've structured things so that the start
> of each section is aligned, but the size is one-byte granular.  Is this
> alignment necessary for any reason apart from allowing RISC machines to read
> the words and half-words in the lto header struct without any worries about
> misaligned access when using mmap?

Yes, that was the reason.  There was even a bug about this somewhen
somewhere ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392