This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] 12843


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'


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]