> Hello all, > > What is the role of executable_checksum from c-common.h & generated by > genchecksum. > > In particular, in the MELT runtime plugin (actually in the MELT branch) > I was supposing it was always defined. However, when referencing it from > melt-runtime.c I got an undefined symbol when linking the lto1 > executable. > > What is the reason of not having executable_checksum inside lto1 binary? > I was naively supposing that writing the checksum of the compiler inside > LTO generated data (e.g. sections in LTO emitted *.o files) is useful, > for example to detect when a *.o LTO-generated by a gcc-4.5.0 was linked > with a *.o LTO-generated by a gcc-4.5.1 (when it will exist).
I believe that longer term strategy is to stabilize LTO format and give every section version (major+minor number) and do checking based on it, to make this particular trick possible. Checksums are used for precompiled headers and possibly some other things I am missing. > > Do we expect to be able to LTO-link a foo.o produced by gcc-4.5.0 -flto > with a bar.o produced by gcc-4.5.1 -flto? I was believing that we don't Probably not in 4.5 series given the shape of LTO code, but for 4.6 I consider this one of goals. > claim that and I was imagining that the executable_checksum could help > on that issue. honza > > The reason I wanted to use executable_checksum is that I was thinking of > emitting its value in the C code foo.c generated by MELT from foo.melt > and checking its dlsym-ed value when dlopen-ing the foo.so module > (dlopen-ed by MELT). This to warn users which uses a foo.so module built > with a slightly different version of MELT. > > Cheers. > > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ > email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 > 8, rue de la Faiencerie, 92340 Bourg La Reine, France > *** opinions {are only mines, sont seulement les miennes} *** >
