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

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

Hi all,

The DWARF standard seems to have fields for the modification time and
file size of each source file that was used to build a binary.
Standard tools like readelf and objdump will display them but by
default, gcc fills the with zero (except for VMS targets):

readelf -wl dwarftest1

.....
 The File Name Table:
  Entry Dir     Time    Size    Name
  1     1       0       0       dwarftest1.cpp
  2     2       0       0       iostream
  3     2       0       0       cstddef
  4     2       0       0       cwchar
....

I patched gcc ( gas from binutils, to more precise ) to fill in
modification time and file size of the source files. The result:

readelf -wl dwarftest1

....
 The File Name Table:
  Entry Dir     Time    Size    Name
  1     1       1352976872      149     dwarftest1.cpp
  2     2       1353406399      2665    iostream
  3     3       1353406307      12542   stddef.h
  4     2       1353406399      1838    cstddef
  5     2       1353406399      6665    cwchar
....

This information can be used to check, if one is debugging the right
source file, or if the source file has changed since compilation,
which leads to displaced stepping and other strange errors.

It can also be used to detect errors like the following:
a program that links to a library and the library itself have been
compiled using different versions of the header files that specify the
library's interface, e.g. data types passed from one to the other.

So why do I post this in gdb ML since GCC/binutils fill in this information?

There are comments in the GCC sources that explain, that GCC fills in
zeros instead of time and size, because some debuggers stop working
correctly when this information is present.

Is this still valid? I think, for gdb and Linux targets its not true.
I have started developing a gdb patch that will check source files
based on the time and size information before setting breakpoints
there or displaying the source.

Does anybody see any problems with this approach that I just havn't
run into yet? And if it works, would the gdb developers support a
change request to GCC/binutils?

regards
Martin