public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: David Carlton <carlton@math.stanford.edu>
To: Andrew Cagney <ac131313@redhat.com>
Cc: Elena Zannoni <ezannoni@redhat.com>,
	Daniel Jacobowitz <drow@mvista.com>, gdb <gdb@sources.redhat.com>,
	Jim Blandy <jimb@redhat.com>
Subject: Re: DW_AT_specification and partial symtabs
Date: Tue, 17 Jun 2003 00:09:00 -0000	[thread overview]
Message-ID: <ro1r85tva34.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <3EE9EFFE.6050607@redhat.com>

On Fri, 13 Jun 2003 11:38:38 -0400, Andrew Cagney
<ac131313@redhat.com> said:

> If psymtab's are dumped (or at least burried) the core GDB <->
> symtab interface is simplified/tightened, people can change the
> internals without breaking everything. David, I belive, has been
> working in that direction.

Yeah.  I was thinking about this a little bit over the weekend (albeit
while not at a computer, so I haven't actually looked at GDB's source
code): from the point of view of looking up symbols by names, I don't
think we have too far to go.  If memory serves me well, the only
functionality that I haven't encapsulated in that regard is symbol
completion and regexp matching.  It would be easy to add methods for
those two to the dictionary interface; once we do that, I think there
would be no particular technical barrier to hiding the psymtab aspect
of name lookup inside the dictionaries.

Though it would take some restructuring of code elsewhere to actually
achieve this: right now, dictionaries live in blocks, and blocks live
in symtabs, not psymtabs.  So if we really want to start getting rid
of psymtabs, we'd have to rethink the symtab/psymtab data structures
themselves, so there's just one place to look for information of
various sorts.  (Which would presumably involve turning them opaque as
well.)  Still, it's a start.

It would be an interesting exercise to think about what interface this
new opaque symtab data structure would export, and how much of that
interface could be implemented lazily in the DWARF 2 case...

David Carlton
carlton@math.stanford.edu

      parent reply	other threads:[~2003-06-17  0:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-12 17:01 David Carlton
2003-06-12 17:05 ` Daniel Jacobowitz
2003-06-12 17:10   ` David Carlton
2003-06-12 17:20   ` Elena Zannoni
2003-06-12 22:17     ` David Carlton
2003-06-13 13:36       ` Daniel Jacobowitz
2003-06-13 14:00         ` Elena Zannoni
2003-06-13 15:38           ` Andrew Cagney
2003-06-13 15:50             ` Daniel Jacobowitz
2003-06-13 15:57               ` Andrew Cagney
2003-06-13 16:24               ` Andrew Cagney
2003-06-13 16:34                 ` Daniel Jacobowitz
2003-06-17  0:09             ` David Carlton [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=ro1r85tva34.fsf@jackfruit.Stanford.EDU \
    --to=carlton@math.stanford.edu \
    --cc=ac131313@redhat.com \
    --cc=drow@mvista.com \
    --cc=ezannoni@redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=jimb@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).