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