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

[Doug Evans <dje at google dot com>]

On Mon, Dec 8, 2014 at 10:04 AM, David Taylor <dtaylor@emc.com> wrote:
>
> 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>
>     }

Ugh.  Got repro?

> 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.


Were .c/.cc files in both lists, or just headers?
It would not be unexpected to find headers in both lists,
but finding .c/.cc files in both lists would be a bug
(assuming things like the .c not being used as a "header",
and all files came from the same objfile).

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


News to me.  Got repro?

>
>
> 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.

Repros for all problems found will help.
We definitely want to help you get past this, stabs needs to die.
(light pun on dwarf intended :-)).