On 02/05/2010 22:38, Gerald Pfeifer wrote:
> #0 diagnostic_action_after_output () at /usr/test/gcc/gcc/diagnostic.c:193
> #1 0x08136d6e in diagnostic_report_diagnostic (context=0x8926400,
> diagnostic=0xbfbfe5f4) at /usr/test/gcc/gcc/diagnostic.c:472
> #2 0x0813754a in internal_error (gmsgid=0x87928df "compressed stream: %s")
> at /usr/test/gcc/gcc/diagnostic.c:757
> #3 0x0827117e in lto_end_uncompression (stream=0x28b03b80)
> at /usr/test/gcc/gcc/lto-compress.c:309
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb)
>
> Now, gcc/doc/install.texi requests libelf version 0.8.12 which is not
> present on this system. Rather, from what I can see FreeBSD has its
> own, independent implementation. And something seems to be broken or
> missing or incompatible here.
This is what I'd expect to see if the sizes of the sections containing
compressed data were being padded to some alignment > 1. The LTO reader
assumes that the section is precisely sized to the data it contains and ends
up passing the padding bytes to the zlib decompressor, which barfs
unpredictably. So, checking the section sizes is the first thing I'd
investigate.
> 1. Tighten the GCC configure checks so that they detect that (if)
> the FreeBSD provided libelf is not sufficient and bail out.
> 2. Fix GCC to work with the FreeBSD provided libelf.
> 3. Fix FreeBSD to sufficiently support GCC (Joseph and Kai on Cc: are
> the respective maintainers there).
>
> How can we best get this resolved?
Probably the most reliable long-term answer is:
4. Fix LTO to store the size of the compressed data at the start of the
section containing it rather than requiring the section to be exactly sized to
the amount of data contained.
cheers,
DaveK
