public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: David Carlton <carlton@bactrian.org>
To: gdb <gdb@sources.redhat.com>
Subject: dwarves, hierarchies, and cross-references
Date: Fri, 09 May 2003 23:14:00 -0000	[thread overview]
Message-ID: <m3ptmryaph.fsf@papaya.bactrian.org> (raw)

Right now the DWARF 2 symbol reader basically proceeds in a
hierarchical fashion: it starts at the DW_TAG_compile_unit entry, then
reads its children, and while reading those children reads their
children, and so forth.  This is good for building up fully qualified
names: e.g. if I have code like

namespace N {
  class C {
    void foo() {} 
  };
}

then it's easy to remember that, when generating the info for 'foo',
we're within a context called 'N::C', so we should really call it
'N::C::foo'.

But that's not the whole story: sometimes one DIE refers to another
DIE somewhere else in the hierarchy.  Typically (always?), these other
DIEs are used to provide type info.  So an example might be:

namespace N {
  class C {
  public:
    class E {};
  };

  class D : public C::E {};
}

Here, N::D has a DW_TAG_inheritance entry that references N::C::E's
DIE.  Now, if I've already traversed N::C::E before traversing N::D, I
probably already know everything about N::C::E.  But if the compiler
happens to emit the info for N::D before the info for N::C (and hence
N::C::E), things get hairier: the reader wants to find info about this
class called E, and it's hard to envision exactly how the reader will
know that, say, the class is really N::C::E (as opposed to, say, E or
N::D::E or N::E or something).

My branch gets this wrong: in situations like the above, it frequently
thinks that D has a base class called N::D::E.  Fortunately, later the
reader generates a correctly named version of the debug info of the
class, so this isn't the end of the world, but it's an unfortunate
situation, because the wrong name lingers in places.

Any suggestions?  Here are some options that I've considered:

* Once we notice that we put E in the wrong context, update everybody
  who has been misled by this.  This seems complicated and potentially
  fragile to me: exactly what data would we have to maintain to make
  this work?

* When parsing E via a cross-reference, figure out its context, so we
  can name it correctly.  This seems like a plausible idea to me; I'm
  only worried that it might be a little inefficient at times.

* Break up the symbol reading into a two-stage process: first, go
  through the hierarchy of DIE's enough to initialize their type
  fields with a bare-bones type, containing enough info for future
  cross-references to be able to use it.  (What exactly needs to be
  filled in?  Certainly the name field; does anything else need to be
  filled in?)  Then go through the hierarchy a second time, filling in
  everything completely.

I think I like the third option the best.  But I'm worried that it
won't be clear what information has to be filled in on the first pass,
and that it also won't be clear exactly how far the first pass will
have to descend the tree; also, it could lead to lots of code
duplication.  (We already look at the tree once for psymtabs and once
for symtabs; breaking the latter up into two passes would make that
even worse.)  If the third option doesn't work, I think the second
option should work: probably the patches on my branch to set names
properly is the only place that we really depend on traversing the
hierarchy in order, in which case tackling the name issue head-on is a
sensible approach.  (Hmm.  Maybe I like the second approach the best.)

Comments?  Suggestions?  Is this explanation of the problem clear at
all?

David Carlton
carlton@bactrian.org

             reply	other threads:[~2003-05-09 23:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-09 23:14 David Carlton [this message]
2003-05-10 19:01 ` Daniel Jacobowitz
2003-05-16 23:23   ` David Carlton

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=m3ptmryaph.fsf@papaya.bactrian.org \
    --to=carlton@bactrian.org \
    --cc=gdb@sources.redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).