From: "André Pönitz" <andre.poenitz@nokia.com>
To: ext Pedro Alves <pedro@codesourcery.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [RFA] 12843
Date: Mon, 29 Aug 2011 12:15:00 -0000 [thread overview]
Message-ID: <201108291417.02082.andre.poenitz@nokia.com> (raw)
In-Reply-To: <201108291112.53906.pedro@codesourcery.com>
On Monday 29 August 2011 12:12:53 ext Pedro Alves wrote:
> > Just using new flags for the parameters should do the trick in this case.
>
> Yeah, though I expect frontends to support letting the user specify
> manually where to insert the breakpoint (say, with a popup dialog
> where you write foo.exe:bar or something more complicated,
It's the IDE's job to capture the user's intentions, i.e. either let the
user provide explicit information about the kind of the breakpoint
(file and line, function, 'on throw' etc) directly in the dialog, or do
the kind of linespec parsing gdb currently does (which feels pretty
unnatural for a "normal" GUI user who typically does not even want
to know what kind of debugging "backend" is used.
But ... it looks like we look at different "frontends" here.
There is a whole spectrum of "debugger frontends" from, let's say
gdb/TUI, ddd etc on one end, which are essentially passing through
user input more or less 1:1, requiring knowledge of exact gdb input
syntax, and "IDEs" that essentially do the job of translating high
level user intentions to "something that makes the backend do the
right thing". A "normal" IDE user does typically not think "Hey, looks
like I am on line 123 in a file called 'foo.cpp', and I know that I have
a gdb backend, with version x.y or better, let's do -break-insert
-f "\"foo.cpp\":123" here." He just presses <F9> or clicks.
Setting a breakpoint by file name and line number covers easily 90%
of all breakpoints ever set through an IDE. Unfortunately, that case
is not as robust with gdb as one would wish, and the "mangling them
into a single string, hoping that gdb can demangle and guess the
original meaning." is part of the problem. Using individual parameters
for specifying different 'aspects' would be more robust.
I am really interested in the IDE case which I believe to be one intented
use case for the MI protocol, and would like to ask to consider choosing
a robust protocol that makes general automated interaction with gdb simple.
Andre'
next prev parent reply other threads:[~2011-08-29 12:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-25 21:59 Keith Seitz
2011-08-26 18:23 ` Tom Tromey
2011-08-26 18:46 ` Keith Seitz
2011-08-26 19:07 ` Tom Tromey
2011-08-27 8:45 ` Eli Zaretskii
2011-08-27 13:17 ` asmwarrior
2011-08-29 19:18 ` Tom Tromey
2011-08-29 7:19 ` André Pönitz
2011-08-29 10:13 ` Pedro Alves
2011-08-29 12:06 ` Matt Rice
2011-08-29 12:15 ` André Pönitz [this message]
2011-08-29 13:53 ` Pedro Alves
2011-08-29 19:21 ` Jan Kratochvil
2011-08-30 8:19 ` André Pönitz
2011-08-30 9:21 ` Jan Kratochvil
2011-08-30 15:02 ` Tom Tromey
2011-08-30 16:34 ` André Pönitz
2011-08-30 17:21 ` Tom Tromey
2011-08-31 8:54 ` André Pönitz
2011-08-29 19:46 ` Tom Tromey
2011-08-29 21:13 ` Keith Seitz
2011-08-30 2:35 ` Daniel Jacobowitz
2011-08-30 15:00 ` Tom Tromey
2011-08-30 17:24 ` Tom Tromey
2011-08-31 18:17 ` Keith Seitz
2011-08-31 18:23 ` Jan Kratochvil
2011-08-31 18:52 ` Tom Tromey
2011-09-02 16:04 ` asmwarrior
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=201108291417.02082.andre.poenitz@nokia.com \
--to=andre.poenitz@nokia.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.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