public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Keith Seitz <keiths@redhat.com>
Cc: archer@sourceware.org
Subject: Re: Expression Parser Plug-In Available
Date: Mon, 14 Mar 2011 18:29:00 -0000	[thread overview]
Message-ID: <m3ei69bloi.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4D79389C.7050500@redhat.com> (Keith Seitz's message of "Thu, 10 Mar 2011 12:46:20 -0800")

Keith> In October, we discussed writing a compiler plug-in to play/experiment
Keith> with the possibility of re-using the compiler's parsers for gdb.

Keith> Well, at long last, I have checked-in an initial version of the
Keith> plug-in to do this.

Very cool.

Keith> I should mention: the plug-in could probably be optimized a bit.  I
Keith> had to resort to some expensive location expansion and strcmp'ing
Keith> filename basenames... In the little playing around that I've done,
Keith> this hasn't really been as big an issue as I would have thought,
Keith> though, but I thought it worth mentioning.

I wouldn't worry about this.  Parsing all the C++ is going to be the
major cost.  And if by some miracle the basename stuff shows up, we can
fix it later.

Keith> The phrase "in-line expression" means that the expression was parsed
Keith> at the location given by the input.  [If parsing fails here, the
Keith> plug-in will continue until the end of the file and try again.  In
Keith> that case, it says "at exit".]

What is that for?

Keith> real	0m12.356s
Keith> user	0m5.123s

Yikes.

Keith> Comments/advice/suggestions -- please send them along!

A couple things...

First, I think we should not worry about the C compiler.  GDB's C parser
is not that bad, and anyway is more maintainable than the C++ stuff,
just because C is so much simpler.  I think it is fine to hack on the C
plugin if it helps you in some way, but if it gets in the way at all,
just ditch it.


Second, I realized recently that current approach will not work at all
with convenience functions.  This is because convenience functions are
untyped.

I think this could be made to work via some evil tricks, but it seems
complicated and hard to make efficient.  (The trick is to do the base
parsing in GDB, using g++ only for name resolution, and do that at
expression-evaluation time.  That way you could invoke the convenience
function before name resolution.  But, this would at least need
memoization to be efficient and would also defer some syntax errors
until the wrong time...)

Tom

      parent reply	other threads:[~2011-03-14 18:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-10 20:46 Keith Seitz
2011-03-10 22:51 ` Keith Seitz
2011-03-14 18:29 ` Tom Tromey [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=m3ei69bloi.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=archer@sourceware.org \
    --cc=keiths@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).