Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: David Carlton <carlton@kealia.com>
Cc: gdb-patches@sources.redhat.com, Elena Zannoni <ezannoni@redhat.com>
Subject: Re: [rfa] classes, partial symtabs, and DW_AT_specification
Date: Sun, 25 Jan 2004 17:00:00 -0000	[thread overview]
Message-ID: <20040125170031.GA10709@nevyn.them.org> (raw)
In-Reply-To: <m34qump4a7.fsf@coconut.kealia.com>

What a coincidence you should raise this subject... :)

On Fri, Jan 23, 2004 at 04:40:48PM -0800, David Carlton wrote:
> When building the partial symbol table for this file, we look for
> definitions of classes; but, when we see the definition for N::C, the
> only way we know from the debug info that we're within namespace N is
> by following DW_AT_specification.  Which we can't do with our
> psymtabs.
> 
> This is a serious design problem with our psymtab structure, which
> we've known about for a while.  Either we need to add into it a fast
> way to follow DW_AT_specification links _and_ then figure out the
> parent of the die at the other end, or we need help from the compiler,
> or something.  In any event, any correct solution would be a major
> undertaking; the best way to deal with the situation for now is to use
> demangled names when we run into this situation, just like we would if
> the compiler weren't generating DW_TAG_namespace at all.

I have no objection to this as a workaround, although it makes me feel
a bit filthy :)

> OK to commit?  I guess I need symtab approval, though Daniel should
> feel free to chime in as well. :-) And at some point we really need to
> develop a plan of attack for DWARF-2 partial symbols - what
> improvements can we do without GCC's help, what help do we want from
> GCC?

We don't need anything from GCC.  We have everything we need already;
we just need to do things (very) differently.  Coincidentally, we
already have another reason to do things differently.  I am working on
inter-CU reference support again; if we can't find parents then there's
no point in building psymtabs, since we won't be able to cope with the
first reference to another CU that isn't nested directly under the CU
DIE.

With a little tuning, I think this is a solvable problem.  It will
probably take a speed hit, but smaller debug info will hopefully make
up for a lot of that.  And then, if someone implements
.debug_info_index, we can use that for psymtabs instead.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  reply	other threads:[~2004-01-25 17:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-24  0:41 David Carlton
2004-01-25 17:00 ` Daniel Jacobowitz [this message]
2004-01-28 18:51   ` David Carlton
2004-01-28 19:59     ` Daniel Jacobowitz
2004-01-28 17:11 ` Elena Zannoni
2004-01-28 18:44   ` 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=20040125170031.GA10709@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=carlton@kealia.com \
    --cc=ezannoni@redhat.com \
    --cc=gdb-patches@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