This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb -- symbols read in? or not read in?
- From: David Taylor <dtaylor at usendtaylorx2l dot lss dot emc dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb <gdb at sourceware dot org>
- Date: Mon, 08 Dec 2014 14:47:16 -0500
- Subject: Re: gdb -- symbols read in? or not read in?
- Authentication-results: sourceware.org; auth=none
- References: <28470 dot 1418061861 at usendtaylorx2l> <CADPb22Tgi6go4N1M8R_beDYxwAMQAwo4+s==ANo3f7hSirG9HQ at mail dot gmail dot com>
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).