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