On Mon, May 24, 2010 at 4:52 AM, Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > Kai, > > I tested your patch posted here: > > http://gcc.gnu.org/ml/gcc/2010-05/msg00445.html > > to address the issue > > % cat x.c > int main() { } > % gccvs -flto x.c > % gccvs -fwhopr x.c > lto1: fatal error: elf_update() failed: Layout constraint violation > compilation terminated. > lto-wrapper: gccvs returned 1 exit status > > which is an appear imcompatibility between FreeBSD's libelf and > gcc's lto. My testing shows that your patch fixes all the problems > I've observed. > > I do however share your concern that gcc may not be following the > ELF spec. Everything that I can find suggests that the alignment > of a section must be the same for all data. The statements on > the web that I've found are of the form: > > When deciding how to build the output file, elf_update obeys the > alignments of individual data buffers to create output sections. > A section's most strictly aligned data buffer controls the section's > alignment. The library also inserts padding between buffers, as > necessary, to ensure the proper alignment of each buffer. > > > It's unclear to me whether FreeBSD libelf is too strict in its > interpretation of the above or whether gcc is to too loose in > its interpretation of what alignment of data means.
It would be nice to fix this on the GCC side (that is, align all sections properly). The reason it is done as now is because we do not record the "true" size of a compressed section and when we have tail-padding zlibg gets confused with the extra bytes. So the issue is really that our compressed sections do not have a header. Richard. > -- > Steve >
