hash signature of cc1 etc....?

hash signature of cc1 etc....?

[Basile Starynkevitch]

Hello All,

As far as I understand, plugins' shared objects are not supposed to (be guaranteed to)
work when gcc changes, even from one patchlevel to the next, or perhaps even when it has
been rebuilt.

In MELT, I am trying very hard to enforce that MELT modules (the *.so produced by
compiling the *.c generated by MELT) are rebuilt when needed, and I even encode in these
*.so some md5sum related to the gcc loading it.

Maybe we should have an easy way to display such checksums.

Should we add an option to the gcc driver which would print such checksums?

Of course, people could use a shell script using the output of gcc -print-file-name=cc1
etc, but I was imagining something simpler, like eg an hypothetical option
gcc -print-internal-checksums

Regards 
-- 
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 mine, sont seulement les miennes} ***

Re: hash signature of cc1 etc....?

[Ian Lance Taylor]

Basile Starynkevitch <basile@starynkevitch.net> writes:

> Should we add an option to the gcc driver which would print such checksums?

I'm not quite sure what checksums you want.

Suppose you just do

md5sum `gcc --print-file-name=cc1`

?

That will give you a checksum without gcc going to the trouble of
generating it.

Ian

Re: hash signature of cc1 etc....?

[Basile Starynkevitch]

On Fri, 22 Jul 2011 15:12:36 -0700
Ian Lance Taylor <iant@google.com> wrote:

> Basile Starynkevitch <basile@starynkevitch.net> writes:
> 
> > Should we add an option to the gcc driver which would print such checksums?
> 
> I'm not quite sure what checksums you want.
> 
> Suppose you just do
> 
> md5sum `gcc --print-file-name=cc1`
> 
> ?
> 
> That will give you a checksum without gcc going to the trouble of
> generating it.


What about the other files. (lto1, cc1plus...). On my Debian/Sid, 
% gcc --print-file-name=cc1
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1

But 
% ls -F /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/
32/	       crtprec80.o	libgcj-tools.so@	libquadmath.a
cc1*	       ecj1*		libgcj.so@		libquadmath.so@
cc1plus*       gengtype*	libgcj.spec		libssp_nonshared.a
collect2*      gtype.state	libgcj_bc.so		libstdc++.a
crtbegin.o     include/		libgcov.a		libstdc++.so@
crtbeginS.o    include-fixed/	libgij.so@		libsupc++.a
crtbeginT.o    jc1*		libgomp.a		lto-wrapper*
crtend.o       jvgenmain*	libgomp.so@		lto1*
crtendS.o      libgcc.a		libgomp.spec		plugin/
crtfastmath.o  libgcc_eh.a	liblto_plugin.so@
crtprec32.o    libgcc_s.so@	liblto_plugin.so.0@
crtprec64.o    libgcc_s_32.so@	liblto_plugin.so.0.0.0


How can I know which of the above files have some influence on the behavior of GCC
plugins? (This is not true of all, crtbegin.o don't, and I would think that gengtype
don't neither, because I believe that its observable behavior changes only from 4.6 to
4.7, but not much from 4.6.0 to 4.6.1).

I was suggesting adding some way to get the checksums of only the relevant files.

Regards.
-- 
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 mine, sont seulement les miennes} ***

Re: hash signature of cc1 etc....?

[Romain Geissler]

Hi

Le 23 juil. 2011 à 07:45, Basile Starynkevitch a écrit :

> On Fri, 22 Jul 2011 15:12:36 -0700
> Ian Lance Taylor <iant@google.com> wrote:
> 
>> Basile Starynkevitch <basile@starynkevitch.net> writes:
>> 
>>> Should we add an option to the gcc driver which would print such checksums?
>> 
>> I'm not quite sure what checksums you want.
>> 
>> Suppose you just do
>> 
>> md5sum `gcc --print-file-name=cc1`
>> 
>> ?
>> 
>> That will give you a checksum without gcc going to the trouble of
>> generating it.
> 
> 
> What about the other files. (lto1, cc1plus...). On my Debian/Sid, 
> % gcc --print-file-name=cc1
> /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1
> 
> But 
> % ls -F /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/
> 32/	       crtprec80.o	libgcj-tools.so@	libquadmath.a
> cc1*	       ecj1*		libgcj.so@		libquadmath.so@
> cc1plus*       gengtype*	libgcj.spec		libssp_nonshared.a
> collect2*      gtype.state	libgcj_bc.so		libstdc++.a
> crtbegin.o     include/		libgcov.a		libstdc++.so@
> crtbeginS.o    include-fixed/	libgij.so@		libsupc++.a
> crtbeginT.o    jc1*		libgomp.a		lto-wrapper*
> crtend.o       jvgenmain*	libgomp.so@		lto1*
> crtendS.o      libgcc.a		libgomp.spec		plugin/
> crtfastmath.o  libgcc_eh.a	liblto_plugin.so@
> crtprec32.o    libgcc_s.so@	liblto_plugin.so.0@
> crtprec64.o    libgcc_s_32.so@	liblto_plugin.so.0.0.0
> 
> 
> How can I know which of the above files have some influence on the behavior of GCC
> plugins? (This is not true of all, crtbegin.o don't, and I would think that gengtype
> don't neither, because I believe that its observable behavior changes only from 4.6 to
> 4.7, but not much from 4.6.0 to 4.6.1).

Plugins only depends on all the header files (gtype.state might also be useful) that GCC allows plugins to see. After all, it's the only thing that's needed to build a plugin. If headers didn't changed but a .o file did because of some patch, you won't see any change when rebuilding the whole plugin (as plugin won't see them). Plugins are nothing more than shared object build with a bunch of header files. So you just need to correctly write header dependencies in your plugin Makefile and it will just work as needed.

Anyway, GCC plugin API brings you plugin_default_version_check which performs checks on revision number + build configuration. By using this check on runtime, you can be assured that the GCC that run the plugin fits the one that build it.

Romain Geissler

> 
> I was suggesting adding some way to get the checksums of only the relevant files.
> 
> Regards.
> -- 
> 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 mine, sont seulement les miennes} ***