From: Bob Rossi <bob_rossi@cox.net>
To: Jim Ingham <jingham@apple.com>
Cc: Daniel Jacobowitz <drow@false.org>, gdb@sources.redhat.com
Subject: Re: MI query questions
Date: Tue, 30 May 2006 17:41:00 -0000 [thread overview]
Message-ID: <20060530171518.GB31100@brasko.net> (raw)
In-Reply-To: <EABAB67C-AAB4-44A8-AC4F-11DBAEBB9A40@apple.com>
On Tue, May 30, 2006 at 09:59:55AM -0700, Jim Ingham wrote:
> What we did for this is along the lines Daniel suggested. When we
> find multiple matches to a breakpoint, we return "matches", and then
> a list of matches, something like:
>
> ^done,matches={b={index="0",canonical="-[NSException raise]",binary="/
> System/Library/Frameworks/Foundation.framework/Versions/C/
> Foundation",line="0",addr="0x9294d008"},b=
> {index="1",canonical="raise",binary="/usr/lib/
> libSystem.B.dylib",line="0",addr="0x9012f940"}}
>
> Then you have to provide some way for the UI to turn around and set
> the breakpoints it wants to set. You aren't really guaranteed that
> the UI will know how to cons up a breakpoint expression that will
> return the breakpoint you want. We tried using the canonical form,
> and with that and the shared library you could do it mostly, except
> if we start doing things like template breakpoints. So we added a -l
> option to -break-insert that takes a list of the indices and sets the
> breakpoints for that list.
>
> It might have been cleaner to tie the list to the original -break-
> insert command, like having -break-insert pass back a cookie along
> with the matches, and then do:
>
> -break-confirm <cookie> <list>
>
> But I wanted to keep it stateless to make the implementation in gdb
> simpler. So the UI just sends the -break-insert twice, the second
> time with the list. You can also send "-1" for the list, and we will
> automatically accept all the breakpoints.
What about the -interpreter-exec console "b A::func" case?
Thanks,
Bob Rossi
next prev parent reply other threads:[~2006-05-30 17:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-30 3:48 Bob Rossi
2006-05-30 8:20 ` Daniel Jacobowitz
2006-05-30 17:15 ` Jim Ingham
2006-05-30 17:41 ` Bob Rossi [this message]
2006-05-30 17:53 ` Jim Ingham
2006-05-30 17:55 ` Jim Ingham
2006-05-30 17:55 ` Bob Rossi
2006-05-30 18:12 ` Daniel Jacobowitz
2006-05-30 20:14 ` Jim Ingham
2006-05-30 18:27 ` Bob Rossi
2006-05-30 18:56 ` Jim Ingham
2006-05-30 20:46 ` Bob Rossi
2006-05-30 21:11 ` Jim Ingham
2006-05-30 21:15 ` Daniel Jacobowitz
2006-05-30 21:30 ` Jim Ingham
2006-05-31 9:38 ` Daniel Jacobowitz
2006-05-31 13:27 ` Bob Rossi
2006-05-30 17:00 ` Nick Roberts
2006-05-30 17:32 ` Bob Rossi
2006-05-31 10:29 ` Nick Roberts
2006-05-31 13:25 ` Bob Rossi
2006-06-01 0:58 ` Nick Roberts
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=20060530171518.GB31100@brasko.net \
--to=bob_rossi@cox.net \
--cc=drow@false.org \
--cc=gdb@sources.redhat.com \
--cc=jingham@apple.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