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

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

[David Taylor]

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.

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

[Doug Evans]

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

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

[Doug Evans]

On Mon, Dec 8, 2014 at 11:03 AM, Doug Evans <dje@google.com> wrote:
> 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.

btw, I played with this a bit and tripped over this bug.

https://sourceware.org/bugzilla/show_bug.cgi?id=17537

So that's something we need to fix.

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

[David Taylor]

Doug Evans <dje@google.com> wrote:

> On Mon, Dec 8, 2014 at 10:04 AM, David Taylor <dtaylor@emc.com> wrote:
[...]
> > and in both cases GDB responded with
> >
> >     type = struct {
> >         <no data fields>
> >     }
> 
> Ugh.  Got repro?

While I can reproduce it at will, I do not yet have a test file that I
can share.

[...]
> > 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).

I didn't check.  Checking just now I see that it is header files that
are duplicated.  No *.c files and no assbembly files are in both lists.

Why would you expect headers to be in both lists?

Of course, this might just be a weirdness unrelated to my real problem
of member fields not showing up.

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

Not yet.  I'll look into how hard it is to create one.

Current reproduction involves way too many files.  I expect that
reducing it down will take some time.  I was hoping that either it was
reported and I missed it in my searches or that someone had seen it, but
didn't report it, and knew more about it.

> Repros for all problems found will help.

Understood.  As a developer I fully understand that it is very hard to
debug problems that are not reliably reproducible.  And even harder to
verify the fix.

> We definitely want to help you get past this, stabs needs to die.
> (light pun on dwarf intended :-)).

What?  You mean that you want to stab STABS?  ;)

We record macro information in the debug information.

[Aside: the GCC and GDB changes for doing this with STABS were posted
*years* ago but never merged.]

Until GCC 4.7.x which extended DWARF to put all the macro strings
together, using DWARF caused our files to swell to 10+ times the size
with STABS and was therefore a non starter for us.

I'll look into reproduction with a smaller set of files.  If I'm unable
to it'll probably be next year before I can debug it myself (due to the
company's use-it-or-lose-it vacation policy I'll be gone the last couple
of weeks of this month).