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

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

------- Comment #12 from davek at gcc dot gnu dot org  2010-01-17 15:28 -------
(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.

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?  I think zlib should be pretty easy-going
about byte-aligned data streams, so if this is the only reason, it might be
easiest for cygwin (since x86 handles misaligned accesses) to just pack all the
lto sections with one byte alignment /and/ size granularity, and not worry
about the start of each lto data section being aligned or not.

So, would it be OK not to align the LTO sections to POINTER_SIZE?  Or is there
something elsewhere in LTO that requires it?


-- 

davek at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davek at gcc dot gnu dot org


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