Re: Target support needed for LTO

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

On 13/12/2010 17:02, Frederic Riss wrote:
> Hi,
> 
> I tried to enable LTO on my port, but failed to do so. On a stupid
> example, I get:
> 
> $ k1-gcc -flto toto.o print.o
> lto1: internal compiler error: compressed stream: data error
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> lto-wrapper: /work1/friss/tools/open64/osprey/targia32_k1/devimage/bin/k1-gcc
> returned 1 exit status
> collect2: lto-wrapper returned 1 exit status
> 
> I debugged a bit and found out that the deflate finds that the
> compressed data is invalid. I tried to compile with included zlib,
> system zlib, Fedora libelf or self-built libelf, the results are the
> same...

    Hello Frederic,

  This symptom usually means that the assembler is padding the section
containing the compressed data when it generates the IR-containing .o file.
There is no record within the compressed data stream of how long it is
supposed to be(*), so LTO assumes that the /entire/ contents of the section
represents compressed data and feeds it to the decompressor.  If there are a
few trailing bytes of zeroes, they get fed to the decompressor as well and it
gets confused and complains.

  On ELF and COFF we deal with this by setting the section alignment to 1
byte, so that no padding is added and the size of the section exactly matches
the amount of data written to it.

  This can be done in the TARGET_ASM_NAMED_SECTION hook by detecting if the
section name begins with LTO_SECTION_NAME_PREFIX and if so, forcing the
alignment to 1 byte; see for example i386_pe_asm_named_section() in
gcc/config/i386/winnt.c.

> Is there anything except defining TARGET_BUILTIN_DECL that targets
> need to do to have LTO working?

  TARGET_BUILTIN_DECL isn't relevant to LTO, actually.  You may or may not
need to define TARGET_MANGLE_ASSEMBLER_NAME, depending on whether your port
does anything unusual with symbol processing; the default hook works fine for
most targets where it's just a matter of whether or not to prepend an underscore.

> Maybe our linker is somehow mangling
> the IR sections. Is there some way to debug those issues?

  Well, check the theory I suggested above first of all; it's more likely that
the assembler is generating the sections with alignment padding.

    cheers,
      DaveK
-- 
(*) - Yes, this is a design weakness we should try and resolve.