Re: Do not decompress functions sections when copying them to ltrans

[Jan Hubicka <hubicka@ucw.cz>]

> > So would the patch be a lot more difficult if you go down either of
> > the routes above?  (I think I prefer changing lto_header rather
> > than making main_size a bitfield)
> 
> Agreed ;)
Hmm, actually it seems things are difficult. All the headers are already compressed
by zlib:
Contents of section .gnu.lto_.inline.faa6142d1fc0c505:
 0000 789c6362 6062c006 10a20000 ba0007    x.cb`b......... 
Contents of section .gnu.lto_.symbol_nodes.faa6142d1fc0c505:
 0000 789c6362 6062e060 80025606 06f67a06  x.cb`b.`..V...z.
 0010 0600029c 0098                        ......          
Contents of section .gnu.lto_.refs.faa6142d1fc0c505:
 0000 789c6362 60626064 80020000 460006    x.cb`b`d....F.. 
Contents of section .gnu.lto_.decls.faa6142d1fc0c505:
 0000 789c6362 6062d060 6060f80f 0461405a  x.cb`b.```...a@Z
 0010 10881981 d88e0115 80c496a2 8929312c  .............)1,
 0020 6c5870e0 c1d2291c 131a1b1b feffaf4f  lXp...)........O
 0030 6464e104 9ac7cec8 a0c5b0b2 a1a16142  dd............aB
 0040 43c32336 142d118c 898c7c9c 0c0a6006  C.#6.-....|...`.
 0050 0f27030b 58349171 1923135c 0d4b895e  .'..X4.q.#.\.K.^
 0060 32037359 620e9bbb 5fa88233 0300a167  2.sYb..._..3...g
 0070 1a7f                                 ..              
Contents of section .gnu.lto_.symtab.faa6142d1fc0c505:
 0000 76616c00 00040004 00000000 000000a5  val.............
 0010 000000                               ...                                                                                                                                                  
Contents of section .gnu.lto_.opts:                                                                                                                                                             
 0000 272d6d74 756e653d 67656e65 72696327  '-mtune=generic'                                                                                                                                     
 0010 20272d6d 61726368 3d783836 2d363427   '-march=x86-64'                                                                                                                                     
 0020 20272d66 6c746f27 00                  '-flto'.                                                                                                                                            
Contents of section .comment:                                                                                                                                                                   
 0000 00474343 3a202853 55534520 4c696e75  .GCC: (SUSE Linu                                                                                                                                     
 0010 78292034 2e382e33 20323031 34303632  x) 4.8.3 2014062                                                                                                                                     
 0020 37205b67 63632d34 5f382d62 72616e63  7 [gcc-4_8-branc
 0030 68207265 76697369 6f6e2032 31323036  h revision 21206
 0040 345d00                               4].             

as you can see only opts/comment and symtab sections come out decompressed.
The sequence x.cb`b is zlib's header.  The description is here:
https://tools.ietf.org/html/rfc1950#page-4

There don't seem to be unique identifier of the zlib header that would
allow us to tell lto_header apart from zlib, so I don't think I can play
a trick and auto-detect the compression.  As such, I do not think
we can get a header about compression into section w/o breaking
backward compatibility short of inventing our own mallformed zlib
header which we would be sure to be able to tell apart from zlib's.
That would defeat the plan to not increase the section sizes.

I would preffer to go with my current solution until we make a new
"major major" revision of the format where we will have a chance
to drop all this and cleanup other design mistakes of the original
LTO format.

Honza