This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Do not decompress functions sections when copying them to ltrans
- From: Richard Biener <rguenther at suse dot de>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 12 Dec 2015 20:47:58 +0100
- Subject: Re: Do not decompress functions sections when copying them to ltrans
- Authentication-results: sourceware.org; auth=none
- References: <20151211011916 dot GA5527 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1512111016330 dot 4884 at t29 dot fhfr dot qr> <20151211093856 dot GC64791 at kam dot mff dot cuni dot cz> <20151212184739 dot GA94791 at kam dot mff dot cuni dot cz>
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