From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgVUK-00049E-V7 for qemu-devel@nongnu.org; Sun, 26 May 2013 03:35:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgVUE-0002mI-BS for qemu-devel@nongnu.org; Sun, 26 May 2013 03:35:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgVUE-0002m7-3m for qemu-devel@nongnu.org; Sun, 26 May 2013 03:35:26 -0400 Date: Sun, 26 May 2013 10:35:40 +0300 From: "Michael S. Tsirkin" Message-ID: <20130526073540.GA32691@redhat.com> References: <20130522085219.GF7993@redhat.com> <519C8E6C.3000107@redhat.com> <20130522094210.GA24931@redhat.com> <519CA097.5000804@redhat.com> <20130522105034.GA5643@redhat.com> <519CA33E.9010109@redhat.com> <20130522110922.GC5643@redhat.com> <519CA80F.4090502@redhat.com> <20130522113510.GA7707@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] makefile: detect corrupted elf files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Peter Maydell , Anthony Liguori , Markus Armbruster , qemu-devel@nongnu.org, Luiz Capitulino , Paolo Bonzini On Sat, May 25, 2013 at 05:32:24PM +0000, Blue Swirl wrote: > On Wed, May 22, 2013 at 11:35 AM, Michael S. Tsirkin w= rote: > > On Wed, May 22, 2013 at 01:12:15PM +0200, Paolo Bonzini wrote: > >> Il 22/05/2013 13:09, Michael S. Tsirkin ha scritto: > >> > > Usually I do the same---I just do slightly more thorough testing= for > >> > > configure patches. > >> > > >> > I've no idea what happens with ccache on a crash by the way. > >> > It's possible that it's careful to do renames in order to not leav= e > >> > corrupted output files behind. > >> > >> It doesn't, it leave 0-sized files. (Or at least it didn't last tim= e > >> power failed during a compilation. :)) > >> > >> Paolo > > > > Well looking at the source, there's quite a bit of > > handling of renames, so maybe ccache hackers will be > > interested in fixing this. > > > > Manpage says: > > It should be noted that ccache is susceptible to general stora= ge > > problems. If a bad object file sneaks into the cache for some= reason, it > > will of course stay bad. Some possible reasons for erroneous = object > > files are bad hardware (disk drive, disk controller, memory, = etc), buggy > > drivers or file systems, a bad CCACHE_PREFIX command or compi= ler > > wrapper. > > > > ... > > > > > > There are no reported issues about ccache producing broken obj= ect > > files reproducibly. That doesn=E2=80=99t mean it can=E2=80=99t= happen, so if you find > > a repeatable case, please report it. > > > > power failure is not listed ... >=20 > Neither is kill -9 issued by evil BOFH. So presumably ccache will not fill with junk if you do this. > IIRC I've also had bad builds > and weird errors because the disk was almost completely full (not > necessarily due to ccache). Once I overclocked a machine but I had to > reduce the speed because of random compile errors. This could be a parallel build, and possibly we have some missing dependencies in the makefile. >=20 > But I think your patch is way too simple to cover possible failure > cases when you can't trust the compile environment. That's not the intent. Merely to address the common failure which I personally observe all the time. > Maybe you should > build in two separate directories and compare the resulting objects or > just the final executables. For added paranoia, build using two > machines which have different set of components from different > manufacturers, but identical userland. >=20 > Another way to handle this would be to enhance GCC and linker to use > atomic operations when producing or combining object files. The tools > could also print a SHA of the object which the next user should > verify. Even better, the object files should include a robust checksum > to ensure integrity. I think we can make the makefile more robust. It can create a temporary file in same directory and rename when ready. This will prevent corrupted files from appearing in the first place. > > > > -- > > MST