From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18327 invoked by alias); 14 Jan 2013 12:31:05 -0000 Received: (qmail 18263 invoked by uid 22791); 14 Jan 2013 12:31:04 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-ie0-f174.google.com (HELO mail-ie0-f174.google.com) (209.85.223.174) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Jan 2013 12:30:51 +0000 Received: by mail-ie0-f174.google.com with SMTP id c11so4876354ieb.33 for ; Mon, 14 Jan 2013 04:30:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.119.16 with SMTP id z16mr62395064icq.51.1358164811069; Mon, 14 Jan 2013 04:00:11 -0800 (PST) Received: by 10.64.102.233 with HTTP; Mon, 14 Jan 2013 04:00:10 -0800 (PST) In-Reply-To: <20130113055406.GX3567@adacore.com> References: <201301130519.r0D5JQJJ016059@new.toad.com> <20130113055406.GX3567@adacore.com> Date: Mon, 14 Jan 2013 12:31:00 -0000 Message-ID: Subject: Re: RFC: include mod time and size in DWARF file name table From: Martin Runge To: Joel Brobecker Cc: John Gilmore , gdb@sourceware.org, Martin Runge Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00050.txt.bz2 Thanks for your replies, I now understand that just looking at the modification time (and size) is not exact enough: We often use code generators in our tooling (moc, uic, resource compiler from Qt, as well as flex, bison and many, many more). They generate the source files fed into gcc at build time. So the compiler will put the generation timestamp into the mentioned fields of the debug info, which will differ on every single rebuild even if the sources (those under version control) did not change at all. On thing is about making sure that one uses compatible binaries/symbol files on host and target for remote debugging. This is necessary for gdb to work correctly. The other thing is about finding errors caused by incorrect builds and maybe give gdb the needed features to detect these problems, too. E.g. being able to find out, why the binaries differ, what source file caused the problem. There are still some cases left that stop gdb from working correctly that cannot be solved by binary comparison: Imagine an executable that uses a library. The executable is not changed very often, but the library is rebuild every day. If the library's interface (defined in a header file included by both) changes, you get a process (the executable with the library loaded) that knows two versions of the things defined in that header file. How can this be detected, once the wrong build messed things up? Similar error can be introduced by using different compiler switches or compiler versions, possibly with different defines set by default for building both. Actually its about debugging your build system. best regards Martin 2013/1/13 Joel Brobecker : >> Yes. The big problem with this approach is that you can never compile >> the same source code files to produce the same binary code files. > [snip] > > I can also confirm that he have had many reports about this as well. > > -- > Joel