public inbox for
 help / color / mirror / Atom feed
From: Tom Tromey <>
To: Project Archer <>
Subject: update on ambiguous linespec branch
Date: Thu, 25 Aug 2011 20:53:00 -0000	[thread overview]
Message-ID: <> (raw)

I'm taking some time off soon, and I wanted to send out an update about
the state of my branch before disappearing.

The project is to implement the "ambiguous linespec" proposal as
discussed on gdb-patches.  The branch is
archer-tromey-ambiguous-linespec.  There is a tracking bug: It depends on all
the bugs that I think will be fixed; in fact most of them are already
fixed on the branch.

Right now most of the new functionality is implemented on the branch.
Nearly all of the work is in linespec, with a little spilling over into
breakpoint.c.  Most of the work was changing linespec to iterate instead
of being satisfied with a single successful lookup.

Here's my remaining to-do list.  I will work on it before my break, but
probably won't finish it.

* I totally broke ranged breakpoints, in fact I #if'd out some of the
  code as a temporary hack.

  It isn't clear to me how ranged breakpoints should actually work if
  there are multiple matches.  Any thoughts?

  One idea I had was to have break-range give an error if the first
  linespec has multiple matches (perhaps defaulting to
  multiple-symbols=ask for this code), then when resolving the second
  linespec, pick the SAL whose PC is closest (but still greater than)
  the PC in the first linespec.

  This may not work supremely well when re-setting, though, since that
  can cause multiple matches when there were none before.

  Also, as an aside, if someone has a use case for break-range, I'm
  curious to know what it is.  I couldn't think of when I would use it.

* Documentation updates.

* I didn't yet implement the new linespec types, namely allowing
  "OBJFILE:" as a prefix, or "FILE:FUNCTION:LINE" or

  I have an idea that we can do this by breaking the linespec up into
  tokens before trying to figure out what the tokens mean, consolidating
  a lot of the lexing logic.  (Which I think is one of the main ugly
  things in linespec.)

  I don't think this item is really needed for the patch to go in.  It
  could be done as a follow-up, and IMO would be better that way, since
  it will be a second huge change to linespec.c.

* struct breakpoint should drop the pspace and gdbarch fields.
  It seems possible to do, though it is hard to be completely sure.

* Audit all the other linespec callers to make sure they are doing the
  right thing.  I think in many cases this will mean using
  multiple-symbols=ask.  However, this is slightly weird since the menu
  just selects between different canonical forms; but a given canonical
  form may still mean multiple locations.

* I have thought about resurrecting my I/T set code from
  archer-tromey-multi-inferior.  Now that linespec iterates over
  program spaces this would actually be pretty useful, I think.
  I suspect it would be better to do this as a follow-up patch.

* Once it is all working I plan to rebase the SystemTap patches on top
  of this branch.


             reply	other threads:[~2011-08-25 20:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-25 20:53 Tom Tromey [this message]
2011-08-26  1:41 ` [Archer] " Joel Brobecker
2011-08-26  2:08   ` Tom Tromey
2011-08-26  1:45 ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* 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).