Re: [PATCH] Add .gnu.lto_.meta section.

[Richard Biener <richard.guenther@gmail.com>]

On Mon, Jun 24, 2019 at 2:12 PM Martin Liška <mliska@suse.cz> wrote:
>
> On 6/24/19 2:02 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 4:01 PM Martin Liška <mliska@suse.cz> wrote:
> >>
> >> On 6/21/19 2:57 PM, Jan Hubicka wrote:
> >>> This looks like good step (and please stream it in host independent
> >>> way). I suppose all these issues can be done one-by-one.
> >>
> >> So there's a working patch for that. However one will see following errors
> >> when using an older compiler or older LTO bytecode:
> >>
> >> $ gcc main9.o -flto
> >> lto1: fatal error: bytecode stream in file ‘main9.o’ generated with LTO version -25480.4493 instead of the expected 9.0
> >>
> >> $ gcc main.o
> >> lto1: internal compiler error: compressed stream: data error
> >
> > This is because of your change to bitfields or because with the old
> > scheme the header with the
> > version is compressed (is it?).
>
> Because currently also the header is compressed.

That was it, yeah :/  Stupid decisions in the past.

I guess we have to bite the bullet and do this kind of incompatible
change, accepting
the odd error message above.

> > I'd simply avoid any layout changes
> > in the version check range.
>
> Well, then we have to find out how to distinguish between compression algorithms.
>
> >
> >> To be honest, I would prefer the new .gnu.lto_.meta section.
> >> Richi why is that so ugly?
> >
> > Because it's a change in the wrong direction and doesn't solve the
> > issue we already
> > have (cannot determine if a section is compressed or not).
>
> That's not true, the .gnu.lto_.meta section will be always uncompressed and we can
> also backport changes to older compiler that can read it and print a proper error
> message about LTO bytecode version mismatch.

We can always backport changes, yes, but I don't see why we have to.

> > ELF section overhead
> > is quite big if you have lots of small functions.
>
> My patch is actually shrinking space as I'm suggesting to add _one_ extra ELF section
> and remove the section header from all other LTO sections. That will save space
> for all function sections.

But we want the header there to at least say if the section is
compressed or not.
The fact that we have so many ELF section means we have the redundant version
info everywhere.

We should have a single .gnu.lto_ section (and also get rid of those
__gnu_lto_v1 and __gnu_lto_slim COMMON symbols - checking for
existence of a symbol is more expensive compared to existence
of a section).

Richard.

> Martin
>
> >
> > Richard.
> >
> >>
> >> Martin
>