[ccache] Re: [Cachecc1-list] cachecc1

Simon Braunschmidt sbraunschmidt.linuxlists at googlemail.com
Tue Apr 8 17:52:08 GMT 2008


Take special care when it comes to source code files that include
other files into them.
While cachecc1 while most probably take care of all kinds of #include,
the problem in my case came from an .incbin statement in an assembler
( .S ) file.

In the linux kernel build process the kernel gets built into a
./vmlinux kernel image. From this object some parts are copied into
./arch/arm/boot/Image (im hacking on arm as you can see). The Image
gets gzipped to ./arch/arm/boot/compressed/piggy.gz.

>From the piggy.gz the piggy.o file is compiled:

pseudo assembler code, compare piggy.S:

section .piggydata
:start_
           .incbin "./arch/arm/boot/compressed/piggy.gz"
:end_

The problem seems to be that cachecc1 does not see that the source
piggy.S or the parameters to compile piggy.o changed and it does not
know about the binary include in piggy.S, so it serves the compile
request from cache.

The piggy.o the basis for all compressed, self extracting kernel
images, so they will not change but be served from cache all the time
when using cachecc1.

Maybe the .incbin command is new to gcc resp. as and is already
accounted for in ccache, can someone comment on this?

Be aware that the problem may be unnoticed for a while, as it was in
my case, because the resulting binaries may be run as regular, they
only dont get any changes.


2008/4/8, Ross Cameron <ross.cameron at linuxpro.co.za>:
> I still use it for bulk building a LOT of packages for my embedded OS,
>  haven't needed to upgrade in AAAAAAAAGES but would appreciate the
>  project not dying off :(
>
>
>  On Tue, Apr 8, 2008 at 3:09 PM, Simon Braunschmidt
>  <sbraunschmidt.linuxlists at googlemail.com> wrote:
>  > Hi
>  >
>  >  is cachecc1 still supported or used?
>  >
>  >  Last version is 0.3 from 2004.
>  >
>  >  I used it for a while but now i tracked down a bug in the linux kernel
>  >  build system for arm architecture to the usage of cachecc1. The bug
>  >  was actually the resuse of binary data that did in fact change, but
>  >  the assembler call for cachecc1 read it from cache.
>  >
>  >  I can provide a detailed description of the steps to reproduce the
>  >  bug, or compare:
>  >  http://groups.google.com/group/fa.linux.kernel/msg/7ae8172becd5e51f
>  >  (piggy.o gets wrongly compiled with data from cache)
>  >
>  >  It seems that the cachecc1 project is effectively dead so I really
>  >  recommend to make this clear on the link to it from ccache homepage.
>  >
>  >  Best Regards
>  >  Simon Braunschmidt
>  >
>
> >  -------------------------------------------------------------------------
>  >  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  >  Register now and save $200. Hurry, offer ends at 11:59 p.m.,
>  >  Monday, April 7! Use priority code J8TLD2.
>  >  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  >  _______________________________________________
>  >  Cachecc1-list mailing list
>  >  Cachecc1-list at lists.sourceforge.net
>  >  https://lists.sourceforge.net/lists/listinfo/cachecc1-list
>  >
>
>
>
>
>  --
>  I have heard there are troubles of more than one kind.
>  Some come from ahead and some from behind.
>  But I've bought a big bat. I'm all ready you see.
>  Now my troubles are going to have toubles with me!
>  -- Dr. Seuss
>


More information about the ccache mailing list