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

[Richard Biener <rguenther@suse.de>]

On December 12, 2015 7:47:39 PM GMT+01:00, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > 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.

Aww, yeah.  Now I remember.

>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.

OK...

Richard.

>
>Honza