Re: [3/4] RFC: add DWARF index support

[Tom Tromey <tromey@redhat.com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Tom> +/* All offsets in the index are of this type.  It must be
Tom> +   architecture-independent.  */
Tom> +typedef uint32_t offset_type;

Jan> It should be 64bit, Fedora already has to carry 64bit obstack patch
Jan> for >2GB .debug files. I have seen only an artificial reproducer
Jan> for >2GB .debug, no real world case, though.
Jan> http://sourceware.org/ml/libc-alpha/2007-01/msg00090.html

Yeah, thanks.  I will fix this.

My thinking is that we only need 64 bit for CU offsets.  It seems very
unlikely to me that an index file could be bigger than 4G (not 2G, since
the offsets are all unsigned).

Also I have been thinking a little about the 64 bit obstack patch.  I
think we can avoid it by going a different route:

First, if we are mmap()ing debug sections, I doubt we need a 64 bit obstack.
The bulk of the data will just be mapped.

Second, if we have a section we cannot map (say it is compressed or
something), we could just malloc memory for it instead of using the
obstack.  The last "read DWARF in the background" patch has the needed
infrastructure to make this work ok, basically having a destructor
function for sections in dwarf2read.c.

What do you think?

Tom> +   1. The file header.  This is a sequence of values, of offset_type
Tom> +   unless otherwise noted:

Jan> I would prefer there some simple magic (for file(1)).

Good idea, I will do that.

Tom> +   [0] The version number.  Currently 1.
Tom> +   [1] The mtime of the objfile, as a 64-bit little-endian value.

Jan> Do you have some specific needs for storing timestamp into the file?
Jan> When such index files will be packaged by distros it may create needless
Jan> differences across various verifications.  Isn't make(1)-like timestamp
Jan> dependency enough?

If the distro processes modify timestamps, then it seems like we also
could not rely on them to remain ordered.

The timestamp is only there to provide some assurance that the index
really indexes the debug file.  I thought the size alone was not
enough -- but that some real checksum would be too slow.

One idea would be to store the build-id and only verify it if the
objfile has a .note.gnu.build-id section.

Another idea is to make the user use objcopy to put the new data into
the objfile.  I am not very fond of this, though.  In my experiments I
think objcopy had bugs dealing with separate debug files.

Tom