Re: [RFC/dwarf-2] Add support for included files

[Jim Blandy <jimb@redhat.com>]

Picking up a dropped thread from January:

http://sources.redhat.com/ml/gdb-patches/2004-01/msg00015.html

Some comments:

It's fine for GDB core code to assume that the psymtabs mention every
source file in the program.  They're supposed to.  The whole purpose
of the psymtabs is to act as an index for the full symbol information,
so that without taking the time/memory to read full symbols, we can at
least find the compilation unit we do need to read.  If that index
doesn't mention a source file, then it's incomplete.

I'm not too enthusiastic about Eli's suggestion that we put off
scanning for source file names until we get a filename we can't find.
It would help: we can find source files most of the time already, and
when the second scan was needed, it wouldn't be any more work than
what Joel's proposing we do every time.  But it's adding a third phase
to debug reading; I'd prefer to fix this problem without architectural
changes like that, if it's practical.

The original motivation for introducing psymtabs at all was speed:
GDB's startup time was, believe it or not, CPU-bound.  By constructing
only partial symtabs at startup time, we avoided parsing types
(essentially).  How does this patch affect the time GDB takes to start
up on itself?  (If you had some monster program lying around, that
would be better, but if all we've got is a brute...)

If it makes a big speed difference, then let's try ignoring
DW_LNE_define_file, not scanning the line number program, and just
entering the files given in the file_names table as psymtabs.  GCC
doesn't generate DW_LNE_define_file.  If that is much faster, then I
think it'll be okay.

(It's interesting to note that, since DW_LNE_define_file exists, the
mechanisms Dwarf 3 provides for "accelerated access" are insufficient:
there's no way to build a complete index of source file names without
reading the line tables.)