This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]