Re: RFC: include mod time and size in DWARF file name table

[Martin Runge <martin.runge@web.de>]

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 <brobecker@adacore.com>:
>> 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