gdb -- symbols read in? or not read in?

[David Taylor <dtaylor@emc.com>]

We have recently switched from STABS to DWARF for our product.  And are
having some issues with DWARF that we never had with STABS.

The first was that with DWARF, GDB seems to not know about the existence
of most of the header files.

Someone would want to look at something in a header file and would say
something like "list foo.h".  GDB would respond that it didn't know
anything about the header.  If you did "info sources", all the *.c and
assembly files would be listed, but only a small fraction of the header
files.

I've mostly taught them to first do a list of a function in a file (or
even just the first few lines of the file) that includes the header
before trying to do something with the header.

I've gotten push back -- people wanting us to switch back to STABS --
but I've been able to resist it so far.

But, now I've encountered a new problem with DWARF.  I tried

    print <variable>.<member>

where <variable> is an instance of a struct and <member> is a element of
that struct.

I tried

    ptype <struct name>
and
    ptype <variable name>

and in both cases GDB responded with

    type = struct {
	<no data fields>
    }

I tried listing a function within the file that defines the global
veriable and then trying again.  No improvement.

Then I did "info sources" and was rather surprised at the output.  There
were 3379 files mentioned.

There were 680 files in the "Source files for which symbols
have been read in:" list.

And 2699 files in the "Source files for which symbols will be read in on
demand:" list.

All files listed were shown with full paths.  But, the surprising part
was that 598 of the files listed in the first list were also listed in
the second list!

So, were the symbols read in?  Or not read in?  No file should be in
both lists.

Is this a known problem?  I didn't see anything in the bug database
about it.

Anyone know of any workarounds other than possibly adding -readnow to
the GDB startup command line which is unacceptable as it adds MINUTES to
the startup time (and haven't tried it so I don't know if it helps or
not).

If variable.member does not consistently work, I might not be able to
resist the push back to switch back to STABS.

This is with GDB 7.8 on an x86-64 GNU/Linux system.