------- 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
