Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: David Taylor <dtaylor@usendtaylorx2l.lss.emc.com>
To: Doug Evans <dje@google.com>
Cc: gdb <gdb@sourceware.org>
Subject: Re: gdb -- symbols read in? or not read in?
Date: Mon, 08 Dec 2014 19:47:00 -0000	[thread overview]
Message-ID: <29511.1418068036@usendtaylorx2l> (raw)
In-Reply-To: <CADPb22Tgi6go4N1M8R_beDYxwAMQAwo4+s==ANo3f7hSirG9HQ@mail.gmail.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).


      parent reply	other threads:[~2014-12-08 19:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-08 18:04 David Taylor
2014-12-08 19:03 ` Doug Evans
2014-12-08 19:38   ` Doug Evans
2014-12-08 19:47   ` David Taylor [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29511.1418068036@usendtaylorx2l \
    --to=dtaylor@usendtaylorx2l.lss.emc.com \
    --cc=dje@google.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox