public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Tom Tromey <tromey@redhat.com>
Cc: archer@sourceware.org
Subject: Re: Initial psymtab replacement results
Date: Mon, 14 Dec 2009 23:09:00 -0000	[thread overview]
Message-ID: <20091214230947.GA31362@caradoc.them.org> (raw)
In-Reply-To: <m3fx7dqix5.fsf@fleche.redhat.com>

On Mon, Dec 14, 2009 at 03:39:50PM -0700, Tom Tromey wrote:
> I understand the compiler problem.  If we had a program to rewrite the
> appropriate DWARF sections, would that address the problems you have?
> It seems to me that it would.

I guess so; if you allow GDB to automatically invoke said program
(there is prior art for that, too) then it's pretty much identical.  I
still think that you will have long term maintenance problems with
this approach and it will cramp future desire to extend it or change
GDB.  But that's not a provable position.

> FWIW if we were going to do our own cache, I wouldn't put it in a form
> like .debug_gnu_index or .debug_pub*.  I'd just have gdb write out a
> mappable data structure.

Or you could drag another bit of GDB into this century, and use SQLite
or some other in-process database.  Mappable data structures are
tricky; one thing I'd definitely insist on is host neutrality.  IMO
that is not optional.

> One definite positive about the branch is that these changes are a lot
> simpler now.  The psymtab stuff is mostly isolated, and writing a new
> "back end" is reasonably self-contained.

This makes me very happy.

-- 
Daniel Jacobowitz
CodeSourcery

  reply	other threads:[~2009-12-14 23:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-10 21:54 Tom Tromey
2009-12-11 23:10 ` Tom Tromey
2009-12-11 23:59   ` Daniel Jacobowitz
2009-12-14 22:40     ` Tom Tromey
2009-12-14 23:09       ` Daniel Jacobowitz [this message]
2009-12-15 23:39         ` Tom Tromey
2009-12-16  3:01           ` Roland McGrath
2009-12-16 18:20             ` Tom Tromey
2009-12-16 18:57               ` Roland McGrath
2009-12-16 19:46                 ` Tom Tromey
2009-12-16 19:52                   ` Roland McGrath
2009-12-16 18:11           ` Daniel Jacobowitz
2009-12-16 19:31             ` Tom Tromey
2009-12-23 18:29           ` Tom Tromey
2009-12-23 18:35             ` Daniel Jacobowitz
2009-12-24 17:07             ` Tom Tromey
2010-01-06 23:05               ` Tom Tromey
2009-12-17 16:39         ` Paul Pluzhnikov
2009-12-17 16:53           ` Daniel Jacobowitz
2009-12-17 17:20             ` Paul Pluzhnikov
2009-12-17 18:16               ` Daniel Jacobowitz
2009-12-18 23:58                 ` Tom Tromey
2009-12-21 13:54                   ` Daniel Jacobowitz
2009-12-21 21:29                     ` Tom Tromey
2009-12-15  1:04       ` Roland McGrath
2009-12-15 18:36         ` Tom Tromey

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=20091214230947.GA31362@caradoc.them.org \
    --to=drow@false.org \
    --cc=archer@sourceware.org \
    --cc=tromey@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).