On Mon, 2010-06-28 at 16:58 -0700, Ian Lance Taylor wrote: > Basile Starynkevitch <bas...@starynkevitch.net> writes: > > > What is the role of executable_checksum from c-common.h & generated by > > genchecksum. > > It is used for precompiled headers. It verifies that the precompiled > header was generated by precisely the same compiler as the one trying to > use the precompiled header. This approach is used because a precompiled > header is essentially a memory dump of the compiler after parsing the > header. It would not work to use a memory of one compiler in another > compiler.
Thanks for the nice explanation. However, I see a slightly more general use of executable_checksum (or something similar) in plugins. Imagine a plugin that store some information somewhere (e.g. in a database) and which might reload that information later. It could be very useful (for that or such plugin[s]) to store a [nearly] unique identifier of the GCC compiler using it with the data (to avoid reusing the same data with a slightly different GCC compiler, eg 4.5.1 vs 4.5.0). Then that plugin would be happy to use the executable_checksum to avoid nightmares when incorrectly reusing some data with a slightly different compiler. And version information is not exactly adequate (the same gcc 4.5.0 could be built & configured differently). > > What is the reason of not having executable_checksum inside lto1 binary? > > lto1 does not use precompiled headers, and as such does not need > executable_checksum. The executable_checksum variable only appears in > those frontends which need it, namely the C family frontends. But that lto1 could use a plugin such as I imagined above. Perhaps the better way might be to have a checksum identifying libbackend.a? Would that be sensible to add, a libbackend_checksum? Cheers.
