* breaking at for-loop test line
@ 2004-07-29 5:10 Allen Hopkins
2004-07-29 16:29 ` Daniel Jacobowitz
0 siblings, 1 reply; 212+ messages in thread
From: Allen Hopkins @ 2004-07-29 5:10 UTC (permalink / raw)
To: gdb
Is there a way to break at the test statement of a for-loop
on every iteration, the same way a while-loop works? Here's
what I mean:
1 #include <iostream.h>
2
3 int main(int argc, char* argv[])
4 {
5 int i = 0;
6
7 for (i = 0; i < 3; i++) {
8 cout << i << endl;
9 }
10
11 while (i < 6) {
12 cout << i++ << endl;
13 }
14
15 exit(0);
16 }
If I set a breakpoint at line 7, and another at line 11,
and "run" and "continue" until exit, it will only break once
on the for-loop, but it will break on each iteration of the
while-loop. How does this make sense? Is there any way to
get a breakpoint at the top of the for-loop to act like the
while-loop?
Here's the compile command:
> g++ -ggdb -Wno-deprecated -o s s.cpp
There's no optimization going on that I'm not aware of,
is there?
Here's sample gdb output:
(gdb) break 7
Breakpoint 1 at 0x10b04: file s.cpp, line 7.
(gdb) break 11
Breakpoint 2 at 0x10b5c: file s.cpp, line 11.
(gdb) run
Starting program:
/export/home/allenh/projects/metropolis/testing/foodir/s
Breakpoint 1, main (argc=1, argv=0xffbeecac) at s.cpp:7
7 for (i = 0; i < 3; i++) {
(gdb) c
Continuing.
0
1
2
Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11 while (i < 6) {
(gdb) c
Continuing.
3
Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11 while (i < 6) {
(gdb) c
Continuing.
4
Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11 while (i < 6) {
(gdb) c
Continuing.
5
Breakpoint 2, main (argc=1, argv=0xffbeecac) at s.cpp:11
11 while (i < 6) {
(gdb) c
Continuing.
Program exited normally.
(gdb)
Any advice appreciated.
Oh, yeah...
Sun Solaris 2.8
gcc 3.2.2
gdb 6.0
Thanks.
-Allen Hopkins
UC Berkeley
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: breaking at for-loop test line
2004-07-29 5:10 breaking at for-loop test line Allen Hopkins
@ 2004-07-29 16:29 ` Daniel Jacobowitz
2004-07-29 18:58 ` Andre Ancelin
2004-07-30 11:32 ` Eli Zaretskii
0 siblings, 2 replies; 212+ messages in thread
From: Daniel Jacobowitz @ 2004-07-29 16:29 UTC (permalink / raw)
To: Allen Hopkins; +Cc: gdb
On Wed, Jul 28, 2004 at 04:09:14PM -0700, Allen Hopkins wrote:
> Is there a way to break at the test statement of a for-loop
> on every iteration, the same way a while-loop works? Here's
> what I mean:
>
> 1 #include <iostream.h>
> 2
> 3 int main(int argc, char* argv[])
> 4 {
> 5 int i = 0;
> 6
> 7 for (i = 0; i < 3; i++) {
> 8 cout << i << endl;
> 9 }
> 10
> 11 while (i < 6) {
> 12 cout << i++ << endl;
> 13 }
> 14
> 15 exit(0);
> 16 }
>
> If I set a breakpoint at line 7, and another at line 11,
> and "run" and "continue" until exit, it will only break once
> on the for-loop, but it will break on each iteration of the
> while-loop. How does this make sense? Is there any way to
> get a breakpoint at the top of the for-loop to act like the
> while-loop?
What Atul wrote is basically correct; GDB can only pick one breakpoint
location for a particular line number, and it picks the beginning of
the line.
It would be nice if there were a way to set a breakpoint at the
condition, but we don't have enough information to know for sure where
the "condition" part is; and we don't want to always set breakpoints at
every part of a line, because it makes breakpoints on simple statements
that get broken up by ptimization very awkward to work with.
I've been thinking for a while about a better interface for this, but I
haven't come up with one yet.
In the mean time, you can take a look at the disassembly, figure out
where the condition is, and set a breakpoint there using break *<addr>.
GDB could also make it much easier to figure out where the condition is
than it does now...
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: breaking at for-loop test line
2004-07-29 16:29 ` Daniel Jacobowitz
@ 2004-07-29 18:58 ` Andre Ancelin
2004-07-30 11:32 ` Eli Zaretskii
1 sibling, 0 replies; 212+ messages in thread
From: Andre Ancelin @ 2004-07-29 18:58 UTC (permalink / raw)
To: Daniel Jacobowitz, Allen Hopkins; +Cc: gdb
On Thursday 29 July 2004 11:29, Daniel Jacobowitz wrote:
This works.
7 for (i = 0; i < 3;
8 i++) {
9 cout << i << endl;
10 }
with a breakpoint at 8. It will stop for each pass. If you try
7 for (i = 0;
8 i < 3;
9 i++) {
10 cout << i << endl;
11 }
with breakpoints at 7, 8, & 9, you stop at each line once, then at line 9 two
more times, then out. It does not, however, stop again at line 8 for each
pass or at terminus (?). You can, however, add a breakpoint on line 11 and
you will break at the next statement after line 11 upon terminus.
Some might call this style ugly or wasteful, but I have found it much more
debug friendly to leave all conditional tests on lines by themselves. Another
simple example:
if (i < 6 ||
i > 9)
{
<do_something>
}
> On Wed, Jul 28, 2004 at 04:09:14PM -0700, Allen Hopkins wrote:
> > Is there a way to break at the test statement of a for-loop
> > on every iteration, the same way a while-loop works? Here's
> > what I mean:
> >
> > 1 #include <iostream.h>
> > 2
> > 3 int main(int argc, char* argv[])
> > 4 {
> > 5 int i = 0;
> > 6
> > 7 for (i = 0; i < 3; i++) {
> > 8 cout << i << endl;
> > 9 }
> > 10
> > 11 while (i < 6) {
> > 12 cout << i++ << endl;
> > 13 }
> > 14
> > 15 exit(0);
> > 16 }
> >
> > If I set a breakpoint at line 7, and another at line 11,
> > and "run" and "continue" until exit, it will only break once
> > on the for-loop, but it will break on each iteration of the
> > while-loop. How does this make sense? Is there any way to
> > get a breakpoint at the top of the for-loop to act like the
> > while-loop?
>
> What Atul wrote is basically correct; GDB can only pick one breakpoint
> location for a particular line number, and it picks the beginning of
> the line.
>
> It would be nice if there were a way to set a breakpoint at the
> condition, but we don't have enough information to know for sure where
> the "condition" part is; and we don't want to always set breakpoints at
> every part of a line, because it makes breakpoints on simple statements
> that get broken up by ptimization very awkward to work with.
>
> I've been thinking for a while about a better interface for this, but I
> haven't come up with one yet.
>
> In the mean time, you can take a look at the disassembly, figure out
> where the condition is, and set a breakpoint there using break *<addr>.
> GDB could also make it much easier to figure out where the condition is
> than it does now...
--
Andre Ancelin
VP/CTO Adtec Digital, Inc
andrea@adtecinc.com
www.adtecinc.com
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: breaking at for-loop test line
2004-07-29 16:29 ` Daniel Jacobowitz
2004-07-29 18:58 ` Andre Ancelin
@ 2004-07-30 11:32 ` Eli Zaretskii
2004-08-03 19:21 ` Daniel Jacobowitz
1 sibling, 1 reply; 212+ messages in thread
From: Eli Zaretskii @ 2004-07-30 11:32 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: allenh, gdb
> Date: Thu, 29 Jul 2004 11:29:40 -0400
> From: Daniel Jacobowitz <drow@false.org>
>
> I've been thinking for a while about a better interface for this, but I
> haven't come up with one yet.
Does GCC tell us in any way (via the debug info) that a single source
line has more than a single statement?
If not, the only way for GDB to figure that out is to parse the source
code by itself.
> GDB could also make it much easier to figure out where the condition is
> than it does now...
How?
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: breaking at for-loop test line
2004-07-30 11:32 ` Eli Zaretskii
@ 2004-08-03 19:21 ` Daniel Jacobowitz
2004-08-03 20:09 ` Andrew Cagney
0 siblings, 1 reply; 212+ messages in thread
From: Daniel Jacobowitz @ 2004-08-03 19:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: allenh, gdb
On Fri, Jul 30, 2004 at 01:43:28PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 29 Jul 2004 11:29:40 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> >
> > I've been thinking for a while about a better interface for this, but I
> > haven't come up with one yet.
>
> Does GCC tell us in any way (via the debug info) that a single source
> line has more than a single statement?
>
> If not, the only way for GDB to figure that out is to parse the source
> code by itself.
No, it doesn't, but there is more information available from the
machine code than there is from the source code. For "for" statements,
it's conceivable to work out that there are multiple places in the
statement which serve as branch targets, via assembly analysis. Better
would be to record this in the debug info; there's no way to do it,
yet, but someone was bouncing around a proposal to record it in the
line table.
> > GDB could also make it much easier to figure out where the condition is
> > than it does now...
>
> How?
By providing a version of "info line" which described all the ranges of
code belonging to a line instead of just the first one, or by a command
which disassembled an entire line.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: breaking at for-loop test line
2004-08-03 19:21 ` Daniel Jacobowitz
@ 2004-08-03 20:09 ` Andrew Cagney
2004-08-03 20:21 ` Daniel Jacobowitz
0 siblings, 1 reply; 212+ messages in thread
From: Andrew Cagney @ 2004-08-03 20:09 UTC (permalink / raw)
To: Daniel Jacobowitz, Eli Zaretskii, allenh; +Cc: gdb
> On Fri, Jul 30, 2004 at 01:43:28PM +0200, Eli Zaretskii wrote:
>
>>>> > Date: Thu, 29 Jul 2004 11:29:40 -0400
>>>> > From: Daniel Jacobowitz <drow@false.org>
>>>> >
>>>> > I've been thinking for a while about a better interface for this, but I
>>>> > haven't come up with one yet.
>>
>>>
>>> Does GCC tell us in any way (via the debug info) that a single source
>>> line has more than a single statement?
>>>
>>> If not, the only way for GDB to figure that out is to parse the source
>>> code by itself.
>
>
> No, it doesn't, but there is more information available from the
> machine code than there is from the source code. For "for" statements,
> it's conceivable to work out that there are multiple places in the
> statement which serve as branch targets, via assembly analysis. Better
> would be to record this in the debug info; there's no way to do it,
> yet, but someone was bouncing around a proposal to record it in the
> line table.
Does dwarf3 include column information? That would let us break:
for (i ; i < 10 ; i++)
into:
for (i ;
i < 10 ;
i++)
which, at least on a graphics device, could be very effectively
represented to the user - the section of code to next be executed could
be highlighted.
Andrew
>>>> > GDB could also make it much easier to figure out where the condition is
>>>> > than it does now...
>>
>>>
>>> How?
>
>
> By providing a version of "info line" which described all the ranges of
> code belonging to a line instead of just the first one, or by a command
> which disassembled an entire line.
>
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: breaking at for-loop test line
2004-08-03 20:09 ` Andrew Cagney
@ 2004-08-03 20:21 ` Daniel Jacobowitz
0 siblings, 0 replies; 212+ messages in thread
From: Daniel Jacobowitz @ 2004-08-03 20:21 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Eli Zaretskii, allenh, gdb
On Tue, Aug 03, 2004 at 04:08:54PM -0400, Andrew Cagney wrote:
> Does dwarf3 include column information? That would let us break:
>
> for (i ; i < 10 ; i++)
>
> into:
>
> for (i ;
> i < 10 ;
> i++)
>
> which, at least on a graphics device, could be very effectively
> represented to the user - the section of code to next be executed could
> be highlighted.
Hmm, yes - the line table does have a field for column. GCC is working
on tracking columns internally, so after that, it shouldn't be too
difficult to make it output appropriate line table data.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 212+ messages in thread
* Laziness
@ 2005-10-10 20:46 David Lecomber
2005-10-10 20:50 ` Laziness Daniel Jacobowitz
0 siblings, 1 reply; 212+ messages in thread
From: David Lecomber @ 2005-10-10 20:46 UTC (permalink / raw)
To: gdb
Hi Folks,
Take a simple code with a big array...
#include <stdio.h>
int main()
{
double x[1000][1000];
printf("hello mum");
}
and ask gdb to "set print elements 1", then break at the printf, and say
"output x".
It takes a while.. (not as much as it used to on Linux thanks to
the /proc memory reading recently committed) but on other platforms it
literally sucks.
The busy bit of the stack is here:
#6 0x0807f37b in target_read_memory (memaddr=3207201336,
myaddr=0xb5e49048 "", len=8000000) at target.c:1000
#7 0x08084a5a in read_memory (memaddr=3207201336, myaddr=0xb5e49048 "",
len=8000000) at corefile.c:239
#8 0x080e2509 in value_fetch_lazy (val=0xb5e49008) at valops.c:515
#9 0x080dc4fb in value_contents_all (value=0xb5e49008) at value.c:331
#10 0x08167551 in c_value_print (val=0xb5e49008, stream=0x91ea940,
format=0, pretty=Val_pretty_default)
at c-valprint.c:596
#11 0x080eb0f4 in print_formatted (val=0xb5e49008, format=0, size=0,
stream=0x91ea940) at .././gdb/printcmd.c:335
#12 0x080eb776 in output_command (exp=0x91ea9a7 "x", from_tty=1)
at .././gdb/printcmd.c:985
Should we really really be reading all that memory, just to print the
first element? I mean, not only is that slow, but it imposes a memory
overhead in the GDB too!
Should we be using a better method?
Cheers
David
--
David Lecomber <david@lecomber.net>
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Laziness
2005-10-10 20:46 Laziness David Lecomber
@ 2005-10-10 20:50 ` Daniel Jacobowitz
2005-10-10 21:05 ` Laziness David Lecomber
0 siblings, 1 reply; 212+ messages in thread
From: Daniel Jacobowitz @ 2005-10-10 20:50 UTC (permalink / raw)
To: David Lecomber; +Cc: gdb
On Mon, Oct 10, 2005 at 10:04:09PM +0100, David Lecomber wrote:
> Hi Folks,
>
> Take a simple code with a big array...
>
> #include <stdio.h>
> int main()
> {
> double x[1000][1000];
> printf("hello mum");
> }
>
> and ask gdb to "set print elements 1", then break at the printf, and say
> "output x".
This is an inherent problem with the implementation of "set print
elements". It prints only one _visible_ element, possibly with a
<repeats %u times> marker. Search for that in valprint.c to see how
this works.
Perhaps we should redefine set print elements to only print anything
pertaining to the original number of elements.
> Should we really really be reading all that memory, just to print the
> first element? I mean, not only is that slow, but it imposes a memory
> overhead in the GDB too!
Not really, for the latter complaint; we discard them as they're read
in.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Laziness
2005-10-10 20:50 ` Laziness Daniel Jacobowitz
@ 2005-10-10 21:05 ` David Lecomber
2005-10-10 21:09 ` Laziness Daniel Jacobowitz
0 siblings, 1 reply; 212+ messages in thread
From: David Lecomber @ 2005-10-10 21:05 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
> Perhaps we should redefine set print elements to only print anything
> pertaining to the original number of elements.
That's a fine idea!
> > Should we really really be reading all that memory, just to print the
> > first element? I mean, not only is that slow, but it imposes a memory
> > overhead in the GDB too!
>
> Not really, for the latter complaint; we discard them as they're read
> in.
Well, after they're read in, right? -- so that at peak it could be as
much as the memory of the actual array. Not much of a problem for a
small code, but imagine some vast numerical code where an array is more
than half the actual available memory on the system - then GDB would
fail.. These codes really do exist.
Cheers
David
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Laziness
2005-10-10 21:05 ` Laziness David Lecomber
@ 2005-10-10 21:09 ` Daniel Jacobowitz
2005-10-10 21:24 ` Laziness David Lecomber
0 siblings, 1 reply; 212+ messages in thread
From: Daniel Jacobowitz @ 2005-10-10 21:09 UTC (permalink / raw)
To: David Lecomber; +Cc: gdb
On Mon, Oct 10, 2005 at 10:22:23PM +0100, David Lecomber wrote:
> > > Should we really really be reading all that memory, just to print the
> > > first element? I mean, not only is that slow, but it imposes a memory
> > > overhead in the GDB too!
> >
> > Not really, for the latter complaint; we discard them as they're read
> > in.
>
> Well, after they're read in, right? -- so that at peak it could be as
> much as the memory of the actual array.
No, as they're read in, one at a time, and compared to the previous
element.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Laziness
2005-10-10 21:09 ` Laziness Daniel Jacobowitz
@ 2005-10-10 21:24 ` David Lecomber
2005-10-10 21:27 ` Laziness Daniel Jacobowitz
0 siblings, 1 reply; 212+ messages in thread
From: David Lecomber @ 2005-10-10 21:24 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
On Mon, 2005-10-10 at 17:09 -0400, Daniel Jacobowitz wrote:
>
> No, as they're read in, one at a time, and compared to the previous
> element.
Err, but I don't think they are. I should've included the top of my
stack:
#1 0x00b3cb1a in ptrace () from /lib/libc.so.6
#2 0x0809512a in child_xfer_memory (memaddr=3207201336,
myaddr=0xb5e49048 "", len=8000000, write=0, attrib=0x0,
target=0x8299460) at infptrace.c:437
#3 0x08095766 in child_xfer_partial (ops=0x8299460,
object=TARGET_OBJECT_MEMORY, annex=0x0,
readbuf=0xb5e49048 "", writebuf=0x0, offset=The value of variable
'offset' is distributed across several
locations, and GDB cannot access its value.
) at inftarg.c:541
#4 0x0807eaa7 in target_xfer_partial (ops=0x8299460,
object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0xb5e49048,
writebuf=0x0, offset=3207201336, len=The value of variable 'len' is
distributed across several
locations, and GDB cannot access its value.
) at target.c:863
#5 0x0807ec9f in xfer_using_stratum (object=TARGET_OBJECT_MEMORY,
annex=0x0, offset=3207201336, len=The value of variable 'len' is
distributed across several
locations, and GDB cannot access its value.
)
at target.c:950
#6 0x0807f37b in target_read_memory (memaddr=3207201336,
myaddr=0xb5e49048 "", len=8000000) at target.c:1000
#7 0x08084a5a in read_memory (memaddr=3207201336, myaddr=0xb5e49048 "",
len=8000000) at corefile.c:239
#8 0x080e2509 in value_fetch_lazy (val=0xb5e49008) at valops.c:515
#9 0x080dc4fb in value_contents_all (value=0xb5e49008) at value.c:331
#10 0x08167551 in c_value_print (val=0xb5e49008, stream=0x91ea940,
format=0, pretty=Val_pretty_default)
at c-valprint.c:596
#11 0x080eb0f4 in print_formatted (val=0xb5e49008, format=0, size=0,
stream=0x91ea940) at .././gdb/printcmd.c:335
#12 0x080eb776 in output_command (exp=0x91ea9a7 "x", from_tty=1)
at .././gdb/printcmd.c:985
That value_contents_all and massive read is happening a good few seconds
before we start doing the repeated elements comparison in
val_print_array_elements..
--
David Lecomber <david@lecomber.net>
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Laziness
2005-10-10 21:24 ` Laziness David Lecomber
@ 2005-10-10 21:27 ` Daniel Jacobowitz
2005-10-10 23:53 ` Laziness Paul Hilfinger
0 siblings, 1 reply; 212+ messages in thread
From: Daniel Jacobowitz @ 2005-10-10 21:27 UTC (permalink / raw)
To: David Lecomber; +Cc: gdb
On Mon, Oct 10, 2005 at 10:42:18PM +0100, David Lecomber wrote:
> That value_contents_all and massive read is happening a good few seconds
> before we start doing the repeated elements comparison in
> val_print_array_elements..
Then that's a different issue: gdb must just not support reading array
elements lazily... that will take more work to fix.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Laziness
2005-10-10 21:27 ` Laziness Daniel Jacobowitz
@ 2005-10-10 23:53 ` Paul Hilfinger
0 siblings, 0 replies; 212+ messages in thread
From: Paul Hilfinger @ 2005-10-10 23:53 UTC (permalink / raw)
To: David Lecomber; +Cc: gdb, hilfingr
> On Mon, Oct 10, 2005 at 10:42:18PM +0100, David Lecomber wrote:
> > That value_contents_all and massive read is happening a good few seconds
> > before we start doing the repeated elements comparison in
> > val_print_array_elements..
>
> Then that's a different issue: gdb must just not support reading array
> elements lazily... that will take more work to fix.
That's right. For Ada, it's been a recurring problem, possibly
because Ada allows one to explicitly describe arrays whose size is
data-dependent. So far we (AdaCore) has kludged around the resulting
performance problems in GDB in piecemeal fashion. Perhaps this would
be a good time to consider more elegant and general approaches, if
they will find an audience outside Ada.
Of course, one can do this "by hand" (or by hand-crafted user-defined
command) with explicit pointer hacking, but perhaps we might seek a
more user-friendly solution.
An obvious approach is to re-do the struct value API to further
lazify (sedate?) it. Currently, values are fetched when needed, but
a. GDB pre-allocates space for the whole eventual value, however huge,
and
b. When the value is delazified, GDB fetches the entire object.
With some enhancements to the struct value API and better enforcement
of its proper use, we could introduce a scheme that
a. Lazily allocated memory, as well as lazily fetching.
b. Allowed for lazily slicing out subcomponents of a composite
value without GDB memory allocation for the target data.
On a separate but related note, I also envision a kind of "struct
value iterator" that allows one to sequence through a composite object
with a single struct value object, avoiding even the creation of new
struct values. Such a mechanism could replace what the print routines
use now, which is basically a method of fetching target memory given
an address and type that is completely independent of the the struct
value mechanism. There would be no functional improvement, but I
imagine we could clean things up a bit.
If any of this elicits interest, we might be persuaded to do the work.
Paul Hilfinger
AdaCore consultant
^ permalink raw reply [flat|nested] 212+ messages in thread
[parent not found: <200508292030.NAA29909@hpsje.cup.hp.com>]
* backtrace changes current source location
@ 2004-10-26 14:49 Felix Lee
2004-10-28 13:49 ` Daniel Jacobowitz
0 siblings, 1 reply; 212+ messages in thread
From: Felix Lee @ 2004-10-26 14:49 UTC (permalink / raw)
To: gdb list
after doing a backtrace, the current source location is set to
the last frame in the backtrace, which is often main(). this
doesn't seem like useful behavior. I think backtrace shouldn't
change the current source location at all, but it's been that way
since gdb 5.3.
this is when the change happened:
http://sources.redhat.com/ml/gdb-patches/2002-08/msg00358.html
any time frame info gets printed, the current source location is
set to that frame, which seems reasonable to me, but it causes
this awkward backtrace behavior.
maybe backtraces should be considered a special case, and
stack.c:backtrace_command_1 should save/restore the current
source location around the call to print_frame_info?
--
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: backtrace changes current source location
2004-10-26 14:49 backtrace changes current source location Felix Lee
@ 2004-10-28 13:49 ` Daniel Jacobowitz
0 siblings, 0 replies; 212+ messages in thread
From: Daniel Jacobowitz @ 2004-10-28 13:49 UTC (permalink / raw)
To: Felix Lee; +Cc: gdb list
On Tue, Oct 26, 2004 at 12:51:15AM -0700, Felix Lee wrote:
> after doing a backtrace, the current source location is set to
> the last frame in the backtrace, which is often main(). this
> doesn't seem like useful behavior. I think backtrace shouldn't
> change the current source location at all, but it's been that way
> since gdb 5.3.
>
> this is when the change happened:
> http://sources.redhat.com/ml/gdb-patches/2002-08/msg00358.html
> any time frame info gets printed, the current source location is
> set to that frame, which seems reasonable to me, but it causes
> this awkward backtrace behavior.
>
> maybe backtraces should be considered a special case, and
> stack.c:backtrace_command_1 should save/restore the current
> source location around the call to print_frame_info?
I've been meaning to fix this since 6.0... I think your suggestion is
reasonable; do you want to try it?
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 212+ messages in thread
* Bumping MI protocol
@ 2004-10-06 1:03 Bob Rossi
2004-10-06 5:08 ` Nathan J. Williams
0 siblings, 1 reply; 212+ messages in thread
From: Bob Rossi @ 2004-10-06 1:03 UTC (permalink / raw)
To: GDB
Hi,
I am wondering when the MI protocol gets bumped. Besides an MI command
that has been changed in an incompatible way, or the actual MI output
syntax changing, does the MI version get bumped for other reasons?
For example, say a new mi command gets added to version 5. Does the mi
version then become 6 because a new command has been added?
Or does MI5 at one major release have X MI commands available, and MI5
at another major release have Y MI commands available?
Can the conditions for bumping the MI version be enumerated?
Can this information be documented for all to easily understand?
Can a front end developer find all of the functions available to a
specific version of an MI protocol from the documentation?
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Bumping MI protocol
2004-10-06 1:03 Bumping MI protocol Bob Rossi
@ 2004-10-06 5:08 ` Nathan J. Williams
2004-10-06 11:27 ` Bob Rossi
0 siblings, 1 reply; 212+ messages in thread
From: Nathan J. Williams @ 2004-10-06 5:08 UTC (permalink / raw)
To: Bob Rossi; +Cc: GDB
Bob Rossi <bob@brasko.net> writes:
> I am wondering when the MI protocol gets bumped. Besides an MI command
> that has been changed in an incompatible way, or the actual MI output
> syntax changing, does the MI version get bumped for other reasons?
I'd just like to point out that these questions all seem, to a
not-very-inside observer, highly hypothetical. There's been few enough
revisions of MI (currently on v2?) that the scenarios you want
detailed descriptions of and rules for have generally not come up, and
this (volunteer) community doesn't seem to take kindly to prescriptive
legislation in such areas.
- Nathan
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Bumping MI protocol
2004-10-06 5:08 ` Nathan J. Williams
@ 2004-10-06 11:27 ` Bob Rossi
2004-10-06 12:30 ` Eli Zaretskii
0 siblings, 1 reply; 212+ messages in thread
From: Bob Rossi @ 2004-10-06 11:27 UTC (permalink / raw)
To: Nathan J. Williams; +Cc: GDB
On Tue, Oct 05, 2004 at 10:59:46PM -0400, Nathan J. Williams wrote:
> Bob Rossi <bob@brasko.net> writes:
>
> > I am wondering when the MI protocol gets bumped. Besides an MI command
> > that has been changed in an incompatible way, or the actual MI output
> > syntax changing, does the MI version get bumped for other reasons?
>
> I'd just like to point out that these questions all seem, to a
> not-very-inside observer, highly hypothetical. There's been few enough
> revisions of MI (currently on v2?) that the scenarios you want
> detailed descriptions of and rules for have generally not come up, and
> this (volunteer) community doesn't seem to take kindly to prescriptive
> legislation in such areas.
Exscuse me for being frank, your statements about this question are foolish.
I would like to know if the MI version get's bumped for adding new MI
commands. This is directly related to the implementation of a front end.
Nathan, how could a front end implement an MIX protocol if it doesn't
know what functions that protocol provides?
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Bumping MI protocol
2004-10-06 11:27 ` Bob Rossi
@ 2004-10-06 12:30 ` Eli Zaretskii
2004-10-06 16:38 ` Bob Rossi
[not found] ` <eliz@gnu.org>
0 siblings, 2 replies; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-06 12:30 UTC (permalink / raw)
To: Bob Rossi; +Cc: nathanw, gdb
> Date: Wed, 6 Oct 2004 07:14:36 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: GDB <gdb@sources.redhat.com>
>
> Exscuse me for being frank, your statements about this question are foolish.
I, for one, don't think Nathan's comments are foolish. As a volunteer
project, we shouldn't waste too much time discussing hypothetical
issues.
> Nathan, how could a front end implement an MIX protocol if it doesn't
> know what functions that protocol provides?
No one requires a front end to implement support for features that are
introduced by GDB versions released after the front end is released.
The only way for a front end to support new features is to track GDB
development, and check the GDB and MI versions to know what commands
are safe to use.
Put it differently, even if the MI version would be incremented each
time a new command is added (which IMHO would be an unwise policy),
you would need an update for the front end to support that command.
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Bumping MI protocol
2004-10-06 12:30 ` Eli Zaretskii
@ 2004-10-06 16:38 ` Bob Rossi
2004-10-06 16:45 ` Nathan J. Williams
[not found] ` <eliz@gnu.org>
1 sibling, 1 reply; 212+ messages in thread
From: Bob Rossi @ 2004-10-06 16:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: nathanw, gdb
On Wed, Oct 06, 2004 at 02:10:09PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 6 Oct 2004 07:14:36 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: GDB <gdb@sources.redhat.com>
> >
> > Exscuse me for being frank, your statements about this question are foolish.
>
> I, for one, don't think Nathan's comments are foolish. As a volunteer
> project, we shouldn't waste too much time discussing hypothetical
> issues.
Either one of you, please describe to me which of these questions is
foolish, and I will clearly explain to you why I need to know this
information in order to build a front end.
1. Besides an MI command that has been changed in an incompatible way,
or the actual MI output syntax changing, does the MI version get
bumped for other reasons?
2. Can the conditions for bumping the MI version be enumerated?
3. Can this information be documented for all to easily understand?
4. Can a front end developer find all of the functions available to a
specific version of an MI protocol from the documentation?
> > Nathan, how could a front end implement an MIX protocol if it doesn't
> > know what functions that protocol provides?
>
> No one requires a front end to implement support for features that are
> introduced by GDB versions released after the front end is released.
> The only way for a front end to support new features is to track GDB
> development, and check the GDB and MI versions to know what commands
> are safe to use.
>
> Put it differently, even if the MI version would be incremented each
> time a new command is added (which IMHO would be an unwise policy),
> you would need an update for the front end to support that command.
I also do not think it would be a good idea to bump the version because
of new commands. I am asking because it's not documented anywhere. If
you want the questions to stop, maybe you will see that there is not
enough information avaiable for front end developers to figure these
thngs out.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Bumping MI protocol
2004-10-06 16:38 ` Bob Rossi
@ 2004-10-06 16:45 ` Nathan J. Williams
2004-10-06 19:53 ` Bob Rossi
0 siblings, 1 reply; 212+ messages in thread
From: Nathan J. Williams @ 2004-10-06 16:45 UTC (permalink / raw)
To: Bob Rossi; +Cc: Eli Zaretskii, gdb
Bob Rossi <bob@brasko.net> writes:
> Either one of you, please describe to me which of these questions is
> foolish, and I will clearly explain to you why I need to know this
> information in order to build a front end.
That you need to know this information, or think you need to know this
information, does not imply that it exists. I'm suggesting that MI is
young and unevolved enough that there is no serious body of work in
woking with its evolution. This means that your questions of "What
happens in case X?" are effectively "please spend time deciding what
happens in case X, which has not yet occurred." To put it in other
terms, an unfunded mandate.
I think you'll make much more ground by assuming that none of these
questions have answers, and proposing possible answers (the "can you
use an MI command to check the MI version" thread seems more
productive to me, for example, because it included suggestions whose
merits can be concretely dissussed).
> I am asking because it's not documented anywhere. If
> you want the questions to stop, maybe you will see that there is not
> enough information avaiable for front end developers to figure these
> thngs out.
Yes, I think such things are not documented because they have not been
considered or they have not come up to be handled, not because of a
conspiracy to keep front-end developers in the dark.
- Nathan
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Bumping MI protocol
2004-10-06 16:45 ` Nathan J. Williams
@ 2004-10-06 19:53 ` Bob Rossi
0 siblings, 0 replies; 212+ messages in thread
From: Bob Rossi @ 2004-10-06 19:53 UTC (permalink / raw)
To: Nathan J. Williams; +Cc: Eli Zaretskii, gdb
On Wed, Oct 06, 2004 at 12:41:10PM -0400, Nathan J. Williams wrote:
> Bob Rossi <bob@brasko.net> writes:
>
> > Either one of you, please describe to me which of these questions is
> > foolish, and I will clearly explain to you why I need to know this
> > information in order to build a front end.
>
> That you need to know this information, or think you need to know this
> information, does not imply that it exists. I'm suggesting that MI is
> young and unevolved enough that there is no serious body of work in
> woking with its evolution. This means that your questions of "What
> happens in case X?" are effectively "please spend time deciding what
> happens in case X, which has not yet occurred." To put it in other
> terms, an unfunded mandate.
>
> I think you'll make much more ground by assuming that none of these
> questions have answers, and proposing possible answers (the "can you
> use an MI command to check the MI version" thread seems more
> productive to me, for example, because it included suggestions whose
> merits can be concretely dissussed).
>
> > I am asking because it's not documented anywhere. If
> > you want the questions to stop, maybe you will see that there is not
> > enough information avaiable for front end developers to figure these
> > thngs out.
>
> Yes, I think such things are not documented because they have not been
> considered or they have not come up to be handled, not because of a
> conspiracy to keep front-end developers in the dark.
Thanks, I understand your point of view here. I'll try to refrain from
"what if" questions. However, if I feel they will effect the implementation
of my front end, I'll speak up.
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
[parent not found: <eliz@gnu.org>]
* Re: Bumping MI protocol
[not found] ` <eliz@gnu.org>
@ 2004-10-06 16:57 ` Felix Lee
2004-10-06 17:03 ` Bob Rossi
0 siblings, 1 reply; 212+ messages in thread
From: Felix Lee @ 2004-10-06 16:57 UTC (permalink / raw)
To: gdb
"Eli Zaretskii" <eliz@gnu.org>:
> > From: Bob Rossi <bob@brasko.net>
> > Exscuse me for being frank, your statements about this question are foolish.
>
> I, for one, don't think Nathan's comments are foolish. As a volunteer
> project, we shouldn't waste too much time discussing hypothetical
> issues.
I agree with Eli and Nathan, from a different angle.
I've never tried implementing a gdb front-end, but if I had to do
one, I wouldn't rely on gdb conforming exactly to any particular
specification, because bugs happen, and eliminating all bugs is
not going to happen in my lifetime.
users are unlikely to be happy about restarting a complicated
debugging session when they encounter a bug in the debugger, so a
robust front-end will need to do some sanity checking of the
conversation, and it will also need a method of resynchronizing
the conversation when the sanity checks fail.
if a front-end has this basic adaptability, then it's not that
big a deal if any one-off version of gdb doesn't conform exactly
to spec. so you can concentrate effort on making things work
well for the versions of gdb that are commonly in use.
--
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: Bumping MI protocol
2004-10-06 16:57 ` Felix Lee
@ 2004-10-06 17:03 ` Bob Rossi
0 siblings, 0 replies; 212+ messages in thread
From: Bob Rossi @ 2004-10-06 17:03 UTC (permalink / raw)
To: Felix Lee; +Cc: gdb
On Wed, Oct 06, 2004 at 09:57:27AM -0700, Felix Lee wrote:
> "Eli Zaretskii" <eliz@gnu.org>:
> > > From: Bob Rossi <bob@brasko.net>
> > > Exscuse me for being frank, your statements about this question are foolish.
> >
> > I, for one, don't think Nathan's comments are foolish. As a volunteer
> > project, we shouldn't waste too much time discussing hypothetical
> > issues.
>
> I agree with Eli and Nathan, from a different angle.
>
> I've never tried implementing a gdb front-end, but if I had to do
> one, I wouldn't rely on gdb conforming exactly to any particular
> specification, because bugs happen, and eliminating all bugs is
> not going to happen in my lifetime.
OK, so here it is again. GDB does not plan on supporting people that
generate there parser from the official MI output syntax ( grammar )?
> users are unlikely to be happy about restarting a complicated
> debugging session when they encounter a bug in the debugger, so a
> robust front-end will need to do some sanity checking of the
> conversation, and it will also need a method of resynchronizing
> the conversation when the sanity checks fail.
Yes, the grammar needs to change. This should all be taken into account
during the development of an MI protocol. Tests should be made for every
MI output command, and the output should be tested to make sure they
conform to the syntax.
> if a front-end has this basic adaptability, then it's not that
> big a deal if any one-off version of gdb doesn't conform exactly
> to spec. so you can concentrate effort on making things work
> well for the versions of gdb that are commonly in use.
> --
Yes yes, you want to see me write one large parser that handles
everything and anything thrown at it, including the english language.
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* gdbserver, sysroot, prelink
@ 2004-10-04 17:51 Felix Lee
2004-10-04 18:12 ` Daniel Jacobowitz
0 siblings, 1 reply; 212+ messages in thread
From: Felix Lee @ 2004-10-04 17:51 UTC (permalink / raw)
To: gdb list
if you use gdbserver to debug a program on a remote Fedora Core 2
machine, then you need to set solib-absolute-prefix to a copy of
the shared libraries from that specific machine. you can't use
generic FC2 shared libraries, because 'prelink' in nightly cron
does arbitrary relocation of shared libraries on each machine.
this probably affects any system that uses prelink; I haven't
tried any other than FC2.
I don't think there's anything that needs fixing. just pointing
out that configuring --with-sysroot is basically useless for any
system that uses prelink.
--
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: gdbserver, sysroot, prelink
2004-10-04 17:51 gdbserver, sysroot, prelink Felix Lee
@ 2004-10-04 18:12 ` Daniel Jacobowitz
0 siblings, 0 replies; 212+ messages in thread
From: Daniel Jacobowitz @ 2004-10-04 18:12 UTC (permalink / raw)
To: Felix Lee; +Cc: gdb list
On Mon, Oct 04, 2004 at 10:37:36AM -0700, Felix Lee wrote:
> if you use gdbserver to debug a program on a remote Fedora Core 2
> machine, then you need to set solib-absolute-prefix to a copy of
> the shared libraries from that specific machine. you can't use
> generic FC2 shared libraries, because 'prelink' in nightly cron
> does arbitrary relocation of shared libraries on each machine.
>
> this probably affects any system that uses prelink; I haven't
> tried any other than FC2.
>
> I don't think there's anything that needs fixing. just pointing
> out that configuring --with-sysroot is basically useless for any
> system that uses prelink.
How does this make --with-sysroot useless? That's exactly what sysroot
is supposed to do - point it where you keep the exact libraries of the
machine. I usually point it to an NFS server.
Yes, prelink randomization does invalidate sysroots.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 212+ messages in thread
* probing GDB for MI versions
@ 2004-10-03 17:15 Bob Rossi
2004-10-04 9:00 ` Eli Zaretskii
2004-10-06 19:16 ` Andrew Cagney
0 siblings, 2 replies; 212+ messages in thread
From: Bob Rossi @ 2004-10-03 17:15 UTC (permalink / raw)
To: GDB
Hi,
I want to figure out the best way to probe GDB for the versions of MI
that it supports. If you know of a better way than the one I'm
suggesting below, please let me know.
I want to add a --mi-protocols flag to GDB, and when it is invoked with
this flag, the only thing that it will output is the versions of MI that
it supports each, on it's own line. For example,
gdb --mi-protocols
MI1
MI2
MI3
What does everyone think? With this command, it would be safe to say
that I could always probe GDB to figure out what version of MI the front
end should use with the current GDB.
The only problem with this approach is that it obviously won't work for
GDB's before this command was implemented. However, in that case, the
user can either assume MI1 (if that's the only publically released
version) or they can try MI2.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-03 17:15 probing GDB for MI versions Bob Rossi
@ 2004-10-04 9:00 ` Eli Zaretskii
2004-10-04 13:19 ` Bob Rossi
2004-10-06 19:16 ` Andrew Cagney
1 sibling, 1 reply; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-04 9:00 UTC (permalink / raw)
To: Bob Rossi; +Cc: gdb
> Date: Sun, 3 Oct 2004 13:01:04 -0400
> From: Bob Rossi <bob@brasko.net>
>
> gdb --mi-protocols
> MI1
> MI2
> MI3
>
> What does everyone think? With this command, it would be safe to say
> that I could always probe GDB to figure out what version of MI the front
> end should use with the current GDB.
If at all, I'd prefer this to be an MI command, not a command-line
switch.
It won't solve this problem, of course:
> The only problem with this approach is that it obviously won't work for
> GDB's before this command was implemented. However, in that case, the
> user can either assume MI1 (if that's the only publically released
> version) or they can try MI2.
To solve that, a front end that is willing to support old versions of
GDB will need to have a database of old GDB versions and the MI
versions they supported. A front end could have this database for all
versions of GDB, which is why the benefit from adding the suggested
command is relatively small, IMHO.
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-04 9:00 ` Eli Zaretskii
@ 2004-10-04 13:19 ` Bob Rossi
2004-10-05 9:10 ` Eli Zaretskii
0 siblings, 1 reply; 212+ messages in thread
From: Bob Rossi @ 2004-10-04 13:19 UTC (permalink / raw)
To: Eli Zaretskii, g; +Cc: gdb
On Mon, Oct 04, 2004 at 07:01:28AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 3 Oct 2004 13:01:04 -0400
> > From: Bob Rossi <bob@brasko.net>
> >
> > gdb --mi-protocols
> > MI1
> > MI2
> > MI3
> >
> > What does everyone think? With this command, it would be safe to say
> > that I could always probe GDB to figure out what version of MI the front
> > end should use with the current GDB.
>
> If at all, I'd prefer this to be an MI command, not a command-line
> switch.
Yes, I understand, that was my first idea. However, you can see that
it is a "catch 22". If you do not know what version of MI to start GDB
with, than you can not understand how to parse the output of the MI
commands. So, you can not call an MI function to figure out what version
to start GDB with.
I think it has to be a command line switch, although I'm open to
suggestions.
The more I think about it, we could change the command to be something
like --list-interfaces and it could look something like,
gdb --list-interfaces
annotate1
annotate2
annotate3
mi1
mi2
mi3
> It won't solve this problem, of course:
>
> > The only problem with this approach is that it obviously won't work for
> > GDB's before this command was implemented. However, in that case, the
> > user can either assume MI1 (if that's the only publically released
> > version) or they can try MI2.
>
> To solve that, a front end that is willing to support old versions of
> GDB will need to have a database of old GDB versions and the MI
> versions they supported.
I don't see what the GDB versions have to do with, am I missing
something? I am only interested in the MI versions.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-04 13:19 ` Bob Rossi
@ 2004-10-05 9:10 ` Eli Zaretskii
2004-10-05 12:34 ` Bob Rossi
0 siblings, 1 reply; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-05 9:10 UTC (permalink / raw)
To: Bob Rossi; +Cc: g, gdb
> Date: Mon, 4 Oct 2004 09:12:52 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: gdb@sources.redhat.com
>
> Yes, I understand, that was my first idea. However, you can see that
> it is a "catch 22". If you do not know what version of MI to start GDB
> with, than you can not understand how to parse the output of the MI
> commands.
I don't see any catch: the output of this specific command could be
made very simple so that it will not need any parsing, just some
trivial string matching or at most regexps.
You will need similar machinery for parsing the output of the
command-line switch you suggested.
> > To solve that, a front end that is willing to support old versions of
> > GDB will need to have a database of old GDB versions and the MI
> > versions they supported.
>
> I don't see what the GDB versions have to do with, am I missing
> something? I am only interested in the MI versions.
New MI versions always come with new GDB versions, right?
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-05 9:10 ` Eli Zaretskii
@ 2004-10-05 12:34 ` Bob Rossi
2004-10-06 10:19 ` Eli Zaretskii
0 siblings, 1 reply; 212+ messages in thread
From: Bob Rossi @ 2004-10-05 12:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: g, gdb
On Tue, Oct 05, 2004 at 10:59:37AM +0200, Eli Zaretskii wrote:
> > Date: Mon, 4 Oct 2004 09:12:52 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: gdb@sources.redhat.com
> >
> > Yes, I understand, that was my first idea. However, you can see that
> > it is a "catch 22". If you do not know what version of MI to start GDB
> > with, than you can not understand how to parse the output of the MI
> > commands.
>
> I don't see any catch: the output of this specific command could be
> made very simple so that it will not need any parsing, just some
> trivial string matching or at most regexps.
IMHO, it doesn't matter how easy it is to parse the MI output, it should
be done algorithmically. Simple or complicated, the same MI output
parser that parses the entire MI output syntax should be capable of
parsing the command we are suggesting.
The goal is to find out what versions of MI GDB supports so that you can
start GDB up in the highest compatible mode. Right?
How can you start GDB up in MI mode to ask it for the MI versions it
supports? You don't know what MI modes it supports, so you can not start
it in MI mode. That's the catch 22.
> You will need similar machinery for parsing the output of the
> command-line switch you suggested.
Yes, I understand that adding a new command line switch is not the
greatest idea. However, it is the only thing I can think of that allows
a front end to ask GDB what versions of MI it supports, without actually
needing to know anything about the MI, avoiding the catch 22.
Yes I agree that the output of this command line switch could never
really change, that seems like a pretty negitive point.
> > > To solve that, a front end that is willing to support old versions of
> > > GDB will need to have a database of old GDB versions and the MI
> > > versions they supported.
> >
> > I don't see what the GDB versions have to do with, am I missing
> > something? I am only interested in the MI versions.
>
> New MI versions always come with new GDB versions, right?
I understand now, I think it would be impossible to figure out what
"GDB version" a GDB CVS snapshot is, do you agree? So there would be no
way to use a database.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-05 12:34 ` Bob Rossi
@ 2004-10-06 10:19 ` Eli Zaretskii
2004-10-06 11:47 ` Bob Rossi
0 siblings, 1 reply; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-06 10:19 UTC (permalink / raw)
To: Bob Rossi; +Cc: gdb
> Date: Tue, 5 Oct 2004 08:11:36 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: g@white, gdb@sources.redhat.com
[Could you please remove that "g@white" from the CC list? It bounces,
so I need to manually remove it, which is a pain, as I respond to too
many mails daily to afford editing the headers. If you need that for
your purposes, please use Bcc.]
> > I don't see any catch: the output of this specific command could be
> > made very simple so that it will not need any parsing, just some
> > trivial string matching or at most regexps.
>
> IMHO, it doesn't matter how easy it is to parse the MI output, it should
> be done algorithmically. Simple or complicated, the same MI output
> parser that parses the entire MI output syntax should be capable of
> parsing the command we are suggesting.
That's a given. What I meant to say was that the output of this
command could be so simple (e.g., a simple string with no structure)
that every MI parser would understand that. Thus no catch-22.
> The goal is to find out what versions of MI GDB supports so that you can
> start GDB up in the highest compatible mode. Right?
>
> How can you start GDB up in MI mode to ask it for the MI versions it
> supports? You don't know what MI modes it supports, so you can not start
> it in MI mode. That's the catch 22.
Again, I see no catch. Here's what I had in mind:
foo$ gdb -interpreter=mi
[the starting blurb omitted]
(gdb) -mi-version
mi3
After this, the front end could either (1) quit GDB and restart it
with a "-interpreter=mi2" (say) switch, or (2) modify its parsing to
adapt to MI version 3.
In other words, I don't need to know what MI versions GDB supports to
start it in MI mode.
> > New MI versions always come with new GDB versions, right?
>
> I understand now, I think it would be impossible to figure out what
> "GDB version" a GDB CVS snapshot is, do you agree? So there would be no
> way to use a database.
Someone else already replied to this: the development snapshots do
have a unique version string, which does allow for a database,
although making the database work for snapshots would require some
support code (because you don't want to have an entry for each day
between official releases).
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 10:19 ` Eli Zaretskii
@ 2004-10-06 11:47 ` Bob Rossi
2004-10-06 12:13 ` Dave Korn
0 siblings, 1 reply; 212+ messages in thread
From: Bob Rossi @ 2004-10-06 11:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
On Wed, Oct 06, 2004 at 11:57:56AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 5 Oct 2004 08:11:36 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: g@white, gdb@sources.redhat.com
>
> [Could you please remove that "g@white" from the CC list? It bounces,
> so I need to manually remove it, which is a pain, as I respond to too
> many mails daily to afford editing the headers. If you need that for
> your purposes, please use Bcc.]
Yes, I'm sorry about that.
> > > I don't see any catch: the output of this specific command could be
> > > made very simple so that it will not need any parsing, just some
> > > trivial string matching or at most regexps.
> >
> > IMHO, it doesn't matter how easy it is to parse the MI output, it should
> > be done algorithmically. Simple or complicated, the same MI output
> > parser that parses the entire MI output syntax should be capable of
> > parsing the command we are suggesting.
>
> That's a given. What I meant to say was that the output of this
> command could be so simple (e.g., a simple string with no structure)
> that every MI parser would understand that. Thus no catch-22.
Unfortunately this topic is on two different threads. I feel badly that I
am wasting your time here with bad descriptions of the "catch-22". This
is to help make my opinion clear on why it is a "catch-22" and not
possible.
The front end has parsers for different versions of GDB's MI protocol.
The parser for MI2 may not work for the MI3 protocol.
The parser for the MI3 protocol may not work for the MI2 protocol.
The front end *can not* start up GDB just by using -interpreter=mi
because it doesn't know what parser to use in this situation.
Can we agree on this point for starters?
For instance, if in MI3, the MI output syntax was changed to add a
label for each MI output command to tell the front end what type of
command is being transmitted, or if any incompatible change was added
to the output syntax, than the parser for MI2 and MI3 would not work
with each other.
In this case alone, the front end can not start up GDB with a specific
version of MI. It needs to get from GDB the versions of MI that it
supports, and then start it up in the highest compatible mode.
This is why there needs to be a non-MI command to figure out what MI
versions the current GDB supports. It is also why I am claiming that
there is a catch-22.
> > The goal is to find out what versions of MI GDB supports so that you can
> > start GDB up in the highest compatible mode. Right?
> >
> > How can you start GDB up in MI mode to ask it for the MI versions it
> > supports? You don't know what MI modes it supports, so you can not start
> > it in MI mode. That's the catch 22.
>
> Again, I see no catch. Here's what I had in mind:
>
> foo$ gdb -interpreter=mi
> [the starting blurb omitted]
> (gdb) -mi-version
> mi3
>
> After this, the front end could either (1) quit GDB and restart it
> with a "-interpreter=mi2" (say) switch, or (2) modify its parsing to
> adapt to MI version 3.
If I am proven to be wrong above, then this would be fine with me.
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* RE: probing GDB for MI versions
2004-10-06 11:47 ` Bob Rossi
@ 2004-10-06 12:13 ` Dave Korn
2004-10-06 16:31 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Dave Korn @ 2004-10-06 12:13 UTC (permalink / raw)
To: 'Bob Rossi', 'Eli Zaretskii'; +Cc: gdb
> -----Original Message-----
> From: gdb-owner On Behalf Of Bob Rossi
> Sent: 06 October 2004 12:39
> Unfortunately this topic is on two different threads. I feel
> badly that I
> am wasting your time here with bad descriptions of the
> "catch-22". This
> is to help make my opinion clear on why it is a "catch-22" and not
> possible.
>
> The front end has parsers for different versions of GDB's
> MI protocol.
> The parser for MI2 may not work for the MI3 protocol.
> The parser for the MI3 protocol may not work for the MI2 protocol.
> The front end *can not* start up GDB just by using -interpreter=mi
> because it doesn't know what parser to use in this situation.
> Can we agree on this point for starters?
No, we can't. As long as the output from the -mi-version MI command stays
in the same format, you can always parse that and determine which version to
use. Everything else can change. You can start up with an utterly minimal,
unintelligent parser, that knows nothing except how to send a -mi-version
command and parse the output; that parser can then direct one of your
version-dependent parsers to take over.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 12:13 ` Dave Korn
@ 2004-10-06 16:31 ` 'Bob Rossi'
2004-10-06 16:46 ` Nathan J. Williams
` (2 more replies)
0 siblings, 3 replies; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-06 16:31 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Eli Zaretskii', gdb
On Wed, Oct 06, 2004 at 12:50:34PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: gdb-owner On Behalf Of Bob Rossi
> > Sent: 06 October 2004 12:39
>
> > Unfortunately this topic is on two different threads. I feel
> > badly that I
> > am wasting your time here with bad descriptions of the
> > "catch-22". This
> > is to help make my opinion clear on why it is a "catch-22" and not
> > possible.
> >
> > The front end has parsers for different versions of GDB's
> > MI protocol.
> > The parser for MI2 may not work for the MI3 protocol.
> > The parser for the MI3 protocol may not work for the MI2 protocol.
> > The front end *can not* start up GDB just by using -interpreter=mi
> > because it doesn't know what parser to use in this situation.
> > Can we agree on this point for starters?
>
> No, we can't. As long as the output from the -mi-version MI command stays
> in the same format, you can always parse that and determine which version to
> use.
Dave, you do not understand the problem at all. I do not appreciate your
defininative answer, especially since it is incorrect.
The actual MI output syntax is capable of changing between MI versions.
If the MI4 output syntax (grammar) has an incompatible change with MI3,
then
* the MI3 parser will not even be capable of parsing and building a
parse tree for the MI4 protocol.
* the MI4 parser will not even be capable of parsing and building a
parse tree for the MI3 protocol.
It is not possible to understand the output of the command no matter how
simple it is. If there is no parse tree, then there is no way to
understand the output from GDB.
> Everything else can change. You can start up with an utterly minimal,
> unintelligent parser, that knows nothing except how to send a -mi-version
> command and parse the output; that parser can then direct one of your
> version-dependent parsers to take over.
I don't understand the concept of an "utterly minimal unintelligent parser".
That is rediculous. I am generating a parser from the grammar.
There absolutly needs to be a way for the front end to ask GDB what
versions of the MI protocol it supports.
There is no way the front end can ask GDB what protocols it supports if
it needs to talk to it with an MI protocol. Understood?
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 16:31 ` 'Bob Rossi'
@ 2004-10-06 16:46 ` Nathan J. Williams
2004-10-06 16:55 ` 'Bob Rossi'
2004-10-06 16:57 ` Dave Korn
2004-10-06 17:05 ` Alain Magloire
2 siblings, 1 reply; 212+ messages in thread
From: Nathan J. Williams @ 2004-10-06 16:46 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: Dave Korn, 'Eli Zaretskii', gdb
"'Bob Rossi'" <bob@brasko.net> writes:
> It is not possible to understand the output of the command no matter how
> simple it is. If there is no parse tree, then there is no way to
> understand the output from GDB.
You have constrained yourself to using a formal parser for absolutely
all interaction with GDB output. This constraint is unnecessary. The
suggestions in this thread are "start gdb, hand-check the result from
this particular minimal command, and *then* fire up the full-fledged,
grammar-generated parser, selecting appropriately for the version".
Perhaps you can explain why you feel this constraint to be necessary,
since that appears to be the real point of contention.
- Nathan
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 16:46 ` Nathan J. Williams
@ 2004-10-06 16:55 ` 'Bob Rossi'
2004-10-06 17:04 ` Nathan J. Williams
0 siblings, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-06 16:55 UTC (permalink / raw)
To: Nathan J. Williams; +Cc: Dave Korn, 'Eli Zaretskii', gdb
On Wed, Oct 06, 2004 at 12:45:49PM -0400, Nathan J. Williams wrote:
> "'Bob Rossi'" <bob@brasko.net> writes:
>
> > It is not possible to understand the output of the command no matter how
> > simple it is. If there is no parse tree, then there is no way to
> > understand the output from GDB.
>
> You have constrained yourself to using a formal parser for absolutely
> all interaction with GDB output. This constraint is unnecessary.
O, I see.
It is now a formal requirement of the GDB group to have front
ends write a formal parser for each MI version and
it is also a requirement of the GDB group to have front ends write an
"utterly minimal, unintelligent parser"?
> The
> suggestions in this thread are "start gdb, hand-check the result from
> this particular minimal command, and *then* fire up the full-fledged,
> grammar-generated parser, selecting appropriately for the version".
>
> Perhaps you can explain why you feel this constraint to be necessary,
> since that appears to be the real point of contention.
The whole reason an MI grammar was invented was so that there were no
"utterly minimal, unintelligent parser" nonsense going on in front ends.
I am generating parsers that meet a specification. There is no way I am
interested in writing a "half-fledged" parser to parse the output of an
MI command just to figure out what "full fledged" parser I should use.
This is rediculous and I don't really even consider it an option of
debate.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 16:55 ` 'Bob Rossi'
@ 2004-10-06 17:04 ` Nathan J. Williams
2004-10-06 17:15 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Nathan J. Williams @ 2004-10-06 17:04 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: Dave Korn, 'Eli Zaretskii', gdb
"'Bob Rossi'" <bob@brasko.net> writes:
> It is now a formal requirement of the GDB group
I am not a particular representative of GDB or its formal decisions. I
am mostly in the sidelines of GDB development, though I happen to have
some limited commit access. Please do not mistake my remarks, mostly
informed just by watching this list, as representing the official
decisions of some body to which I do not belong.
> The whole reason an MI grammar was invented was so that there were no
> "utterly minimal, unintelligent parser" nonsense going on in front ends.
Well, if you want to interrogate GDB for what versions it has
avaliable (as in your suggestion for a command line option), you have
to do that somewhere, and that will still take some parsing. Would it
make you happy if the mechanism for doing that was declared, formally,
not to be part of MI and its grammar, but just a suspiciously
similar-looking interactive command?
- Nathan
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 17:04 ` Nathan J. Williams
@ 2004-10-06 17:15 ` 'Bob Rossi'
0 siblings, 0 replies; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-06 17:15 UTC (permalink / raw)
To: Nathan J. Williams; +Cc: Dave Korn, 'Eli Zaretskii', gdb
On Wed, Oct 06, 2004 at 01:03:14PM -0400, Nathan J. Williams wrote:
> "'Bob Rossi'" <bob@brasko.net> writes:
>
> > It is now a formal requirement of the GDB group
>
> I am not a particular representative of GDB or its formal decisions. I
> am mostly in the sidelines of GDB development, though I happen to have
> some limited commit access. Please do not mistake my remarks, mostly
> informed just by watching this list, as representing the official
> decisions of some body to which I do not belong.
>
> > The whole reason an MI grammar was invented was so that there were no
> > "utterly minimal, unintelligent parser" nonsense going on in front ends.
>
> Well, if you want to interrogate GDB for what versions it has
> avaliable (as in your suggestion for a command line option), you have
> to do that somewhere, and that will still take some parsing. Would it
> make you happy if the mechanism for doing that was declared, formally,
> not to be part of MI and its grammar, but just a suspiciously
> similar-looking interactive command?
Yes, that is a great idea! and it would make me even me happy!
GDB -i=list-protocols
mi1
mi2
mi3
annotate1
annotate2
There could be an interpreter that is only capable of outputting the
protocols of MI that it officially supports. We could document that it
will output one officially supported protocol on a line. This would make
me very happy. At the same time, we could output the annotate version
also.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* RE: probing GDB for MI versions
2004-10-06 16:31 ` 'Bob Rossi'
2004-10-06 16:46 ` Nathan J. Williams
@ 2004-10-06 16:57 ` Dave Korn
2004-10-06 17:12 ` 'Bob Rossi'
2004-10-06 17:05 ` Alain Magloire
2 siblings, 1 reply; 212+ messages in thread
From: Dave Korn @ 2004-10-06 16:57 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: 'Eli Zaretskii', gdb
> -----Original Message-----
> From: 'Bob Rossi'
> Sent: 06 October 2004 17:22
> On Wed, Oct 06, 2004 at 12:50:34PM +0100, Dave Korn wrote:
> > > -----Original Message-----
> > > From: gdb-owner On Behalf Of Bob Rossi
> > > Sent: 06 October 2004 12:39
> > > The front end has parsers for different versions of GDB's
> > > MI protocol.
> > > The parser for MI2 may not work for the MI3 protocol.
> > > The parser for the MI3 protocol may not work for the
> MI2 protocol.
> > > The front end *can not* start up GDB just by using
> -interpreter=mi
> > > because it doesn't know what parser to use in this situation.
> > > Can we agree on this point for starters?
> >
> > No, we can't. As long as the output from the -mi-version
> MI command stays
> > in the same format, you can always parse that and determine
> which version to
> > use.
> Dave, you do not understand the problem at all. I do not
> appreciate your
> defininative answer, especially since it is incorrect.
#1. Well, I don't appreciate your rudeness, but hey, we don't always get
what we want in life. Guess you're just SOL.
#2. My answer IS correct. I DO understand the problem, and in fact I
understand it better enough than you do that I can see the very very obvious
solution (that you aren't capable of grasping) as well as the problem
itself.
#3. Why do you have to be the _only_ person in the entire software industry
who isn't capable of dealing with elementary versioning and compatibility
issues? These techniques work fine for EVERYONE else but you.
> The actual MI output syntax is capable of changing between MI
> versions.
Yes. I hope we're all agreed that there is no hope of (nor point to)
tracking a work-in-progress as it changes on a day-by-day basis.
> If the MI4 output syntax (grammar) has an incompatible change
> with MI3,
> then
> * the MI3 parser will not even be capable of parsing and
> building a
> parse tree for the MI4 protocol.
> * the MI4 parser will not even be capable of parsing and building a
> parse tree for the MI3 protocol.
Try and think outside the box. Your over-reliance on tools is hobbling
you. You aren't obliged by statute to use an automatically generated parser
based on a formal grammar. You can use printf to send the -mi-version
command to the gdb instance, and you can use sscanf to parse the version
number out of the string "MI version is XXXX" that it returns.
> It is not possible to understand the output of the command no
> matter how simple it is.
Speak for yourself. I can understand it, it's human readable. I could
write a very very very simple bit of code using sscanf that would understand
it. You might have a problem understanding it, but you're the only one who
does, and there's no need for you to.
>If there is no parse tree, then there is no way to
> understand the output from GDB.
Don't be so facile. You send one very simple command, get back one very
simple output that you can parse with strcmp or sscanf, for crying out loud.
Then you know what MI version you're dealing with.
> I don't understand the concept of an "utterly minimal
> unintelligent parser".
Well, you're clearly biting off more than you can chew with this entire
project. As I said above, something of the degree of complexity of a single
sscanf statement is what I mean.
> That is rediculous. I am generating a parser from the grammar.
>
> There absolutly needs to be a way for the front end to ask GDB what
> versions of the MI protocol it supports.
>
> There is no way the front end can ask GDB what protocols it
> supports if
> it needs to talk to it with an MI protocol. Understood?
I understand what you're claiming, but I gave you a perfectly clear and
simple way of doing it. You haven't demonstrated any problem with my
proposal, because as you said above, you haven't even understood it yet.
When you do understand it, you'll also understand that it works just fine.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 16:57 ` Dave Korn
@ 2004-10-06 17:12 ` 'Bob Rossi'
2004-10-06 17:21 ` Dave Korn
0 siblings, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-06 17:12 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Eli Zaretskii', gdb
Sorry if I was rude here, I am very frustrated.
No one has attempted to do what I am trying to do. Write a front end
that is capable of working with different GDB's.
If they do do this, I would like to know how they negotiate the MI
version to talk.
Again, you seem to be saying that if I generate a parser off of the MI
output syntax, that I am somehow wrong.
Is this the general feel of the community?
Bob Rossi
On Wed, Oct 06, 2004 at 05:55:28PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: 'Bob Rossi'
> > Sent: 06 October 2004 17:22
>
> > On Wed, Oct 06, 2004 at 12:50:34PM +0100, Dave Korn wrote:
> > > > -----Original Message-----
> > > > From: gdb-owner On Behalf Of Bob Rossi
> > > > Sent: 06 October 2004 12:39
>
> > > > The front end has parsers for different versions of GDB's
> > > > MI protocol.
> > > > The parser for MI2 may not work for the MI3 protocol.
> > > > The parser for the MI3 protocol may not work for the
> > MI2 protocol.
> > > > The front end *can not* start up GDB just by using
> > -interpreter=mi
> > > > because it doesn't know what parser to use in this situation.
> > > > Can we agree on this point for starters?
> > >
> > > No, we can't. As long as the output from the -mi-version
> > MI command stays
> > > in the same format, you can always parse that and determine
> > which version to
> > > use.
>
> > Dave, you do not understand the problem at all. I do not
> > appreciate your
> > defininative answer, especially since it is incorrect.
>
> #1. Well, I don't appreciate your rudeness, but hey, we don't always get
> what we want in life. Guess you're just SOL.
>
> #2. My answer IS correct. I DO understand the problem, and in fact I
> understand it better enough than you do that I can see the very very obvious
> solution (that you aren't capable of grasping) as well as the problem
> itself.
>
> #3. Why do you have to be the _only_ person in the entire software industry
> who isn't capable of dealing with elementary versioning and compatibility
> issues? These techniques work fine for EVERYONE else but you.
>
> > The actual MI output syntax is capable of changing between MI
> > versions.
>
> Yes. I hope we're all agreed that there is no hope of (nor point to)
> tracking a work-in-progress as it changes on a day-by-day basis.
>
> > If the MI4 output syntax (grammar) has an incompatible change
> > with MI3,
> > then
> > * the MI3 parser will not even be capable of parsing and
> > building a
> > parse tree for the MI4 protocol.
> > * the MI4 parser will not even be capable of parsing and building a
> > parse tree for the MI3 protocol.
>
> Try and think outside the box. Your over-reliance on tools is hobbling
> you. You aren't obliged by statute to use an automatically generated parser
> based on a formal grammar. You can use printf to send the -mi-version
> command to the gdb instance, and you can use sscanf to parse the version
> number out of the string "MI version is XXXX" that it returns.
>
> > It is not possible to understand the output of the command no
> > matter how simple it is.
>
> Speak for yourself. I can understand it, it's human readable. I could
> write a very very very simple bit of code using sscanf that would understand
> it. You might have a problem understanding it, but you're the only one who
> does, and there's no need for you to.
>
> >If there is no parse tree, then there is no way to
> > understand the output from GDB.
>
> Don't be so facile. You send one very simple command, get back one very
> simple output that you can parse with strcmp or sscanf, for crying out loud.
> Then you know what MI version you're dealing with.
>
> > I don't understand the concept of an "utterly minimal
> > unintelligent parser".
>
> Well, you're clearly biting off more than you can chew with this entire
> project. As I said above, something of the degree of complexity of a single
> sscanf statement is what I mean.
>
> > That is rediculous. I am generating a parser from the grammar.
> >
> > There absolutly needs to be a way for the front end to ask GDB what
> > versions of the MI protocol it supports.
> >
> > There is no way the front end can ask GDB what protocols it
> > supports if
> > it needs to talk to it with an MI protocol. Understood?
>
> I understand what you're claiming, but I gave you a perfectly clear and
> simple way of doing it. You haven't demonstrated any problem with my
> proposal, because as you said above, you haven't even understood it yet.
> When you do understand it, you'll also understand that it works just fine.
>
> cheers,
> DaveK
> --
> Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 212+ messages in thread
* RE: probing GDB for MI versions
2004-10-06 17:12 ` 'Bob Rossi'
@ 2004-10-06 17:21 ` Dave Korn
2004-10-06 17:24 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Dave Korn @ 2004-10-06 17:21 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: 'Eli Zaretskii', gdb
> -----Original Message-----
> From: 'Bob Rossi'
> Sent: 06 October 2004 18:05
> Sorry if I was rude here, I am very frustrated.
It shows. But seriously, if you have to keep on saying the same thing
over and over again, we're not disagreeing with you just to be contrary,
it's because either _we_ haven't understood the problem, or because _you_
haven't understood the solutions we've proposed. At that point, there's a
communication difficulty going on, which will not be resolved by simply
repeating the same description over and over getting more angry each time.
> No one has attempted to do what I am trying to do. Write a front end
> that is capable of working with different GDB's.
>
> If they do do this, I would like to know how they negotiate the MI
> version to talk.
>
> Again, you seem to be saying that if I generate a parser off of the MI
> output syntax, that I am somehow wrong.
No, that's not what I'm saying. I fully accept that you have to know what
version to deal with in order to invoke the correct full parser, and I fully
accept that while in general newer versions are supersets there are also
genuine backwards-incompatibilities that would require different parsing.
It's entirely proper to generate a parser from the MI output syntax.
The only thing I'm disagreeing is your assumption that there's no way of
determining which MI version to talk without using a full MI parser. You
can do it MUCH more simply than that. That's the point which people keep on
having to repeat to you each time you repeat your description of the
problem, because while everyone understands the initial problem, nobody sees
what's wrong with the solutions that have been proposed so far.
> Is this the general feel of the community?
Well, it's not what I feel, as I hope I've explained patiently above. I
wouldn't care to speak for the community at large, but I would be surprised
if anyone else felt that it was wrong to generate a parser from the MI
output syntax. What I feel is wrong is your assumption that a generated
parser is the only possible means of processing plain ascii human readable
text for the purpose of finding and extracting a single integer value.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 17:21 ` Dave Korn
@ 2004-10-06 17:24 ` 'Bob Rossi'
2004-10-06 17:31 ` Daniel Jacobowitz
` (2 more replies)
0 siblings, 3 replies; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-06 17:24 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Eli Zaretskii', gdb
On Wed, Oct 06, 2004 at 06:14:49PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: 'Bob Rossi'
> > Sent: 06 October 2004 18:05
>
> > Sorry if I was rude here, I am very frustrated.
>
> It shows. But seriously, if you have to keep on saying the same thing
> over and over again, we're not disagreeing with you just to be contrary,
> it's because either _we_ haven't understood the problem, or because _you_
> haven't understood the solutions we've proposed. At that point, there's a
> communication difficulty going on, which will not be resolved by simply
> repeating the same description over and over getting more angry each time.
Understood.
> > No one has attempted to do what I am trying to do. Write a front end
> > that is capable of working with different GDB's.
> >
> > If they do do this, I would like to know how they negotiate the MI
> > version to talk.
> >
> > Again, you seem to be saying that if I generate a parser off of the MI
> > output syntax, that I am somehow wrong.
>
> No, that's not what I'm saying. I fully accept that you have to know what
> version to deal with in order to invoke the correct full parser, and I fully
> accept that while in general newer versions are supersets there are also
> genuine backwards-incompatibilities that would require different parsing.
> It's entirely proper to generate a parser from the MI output syntax.
>
> The only thing I'm disagreeing is your assumption that there's no way of
> determining which MI version to talk without using a full MI parser. You
> can do it MUCH more simply than that. That's the point which people keep on
> having to repeat to you each time you repeat your description of the
> problem, because while everyone understands the initial problem, nobody sees
> what's wrong with the solutions that have been proposed so far.
You are the first person so far that has pointed out directly to me that
you understand the problem I am describing.
> > Is this the general feel of the community?
>
> Well, it's not what I feel, as I hope I've explained patiently above. I
> wouldn't care to speak for the community at large, but I would be surprised
> if anyone else felt that it was wrong to generate a parser from the MI
> output syntax. What I feel is wrong is your assumption that a generated
> parser is the only possible means of processing plain ascii human readable
> text for the purpose of finding and extracting a single integer value.
I guess the bottom line is, I already have a parser that is capable of
dealing with a specific version of MI's output. I don't want to start up
MI with an adhoc parser, just to figure out what real parser I should
use. This seems not correct to me, and I guess it's the issue to deal
with.
The problem is, we would be adding a command to the MI function set that
would not be able to be parsed and understood with an MI parser. This
seems really wrong to me. It's probably the issue we should be
discussing.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 17:24 ` 'Bob Rossi'
@ 2004-10-06 17:31 ` Daniel Jacobowitz
2004-10-06 17:38 ` Bob Rossi
2004-10-06 17:36 ` Dave Korn
2004-10-06 17:51 ` Paul Koning
2 siblings, 1 reply; 212+ messages in thread
From: Daniel Jacobowitz @ 2004-10-06 17:31 UTC (permalink / raw)
To: Dave Korn, 'Eli Zaretskii', gdb
On Wed, Oct 06, 2004 at 01:21:38PM -0400, 'Bob Rossi' wrote:
> I guess the bottom line is, I already have a parser that is capable of
> dealing with a specific version of MI's output. I don't want to start up
> MI with an adhoc parser, just to figure out what real parser I should
> use. This seems not correct to me, and I guess it's the issue to deal
> with.
You've got a hammer and are attempting to create a nail. It seems
eminently correct to me, and to Dave too I think.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 17:31 ` Daniel Jacobowitz
@ 2004-10-06 17:38 ` Bob Rossi
2004-10-06 17:41 ` Dave Korn
0 siblings, 1 reply; 212+ messages in thread
From: Bob Rossi @ 2004-10-06 17:38 UTC (permalink / raw)
To: Dave Korn, 'Eli Zaretskii', gdb
On Wed, Oct 06, 2004 at 01:24:03PM -0400, Daniel Jacobowitz wrote:
> On Wed, Oct 06, 2004 at 01:21:38PM -0400, 'Bob Rossi' wrote:
> > I guess the bottom line is, I already have a parser that is capable of
> > dealing with a specific version of MI's output. I don't want to start up
> > MI with an adhoc parser, just to figure out what real parser I should
> > use. This seems not correct to me, and I guess it's the issue to deal
> > with.
>
> You've got a hammer and are attempting to create a nail. It seems
> eminently correct to me, and to Dave too I think.
Unfortunately, I don't understand what this means. Could you please
explain?
I want to make one thing clear, Eli's suggesting of making an MI command
that returns the supported MI versions has one problem. We are adding a
command to an MI protocol that can not be understood by a program that
can speak a protocol. The program must,
1. Have a parser that understands the protocol it wants to speak
(obvious and easy to get)
2. Have a parser that understands all future non invented protocols
of the MI output syntax, and will be capable of parsing the current
and future protocols to get the information it needs.
(mostly not possible)
Will someone explain to me how they expect to write a parser capable of
getting some information out of MI2, but prove to me that it will work
with MI100.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* RE: probing GDB for MI versions
2004-10-06 17:38 ` Bob Rossi
@ 2004-10-06 17:41 ` Dave Korn
2004-10-06 17:55 ` 'Bob Rossi'
2004-10-06 18:43 ` Andrew Cagney
0 siblings, 2 replies; 212+ messages in thread
From: Dave Korn @ 2004-10-06 17:41 UTC (permalink / raw)
To: 'Bob Rossi', 'Eli Zaretskii', gdb
> -----Original Message-----
> From: Bob Rossi [mailto:bob@brasko.net]
> I want to make one thing clear, Eli's suggesting of making an
> MI command
> that returns the supported MI versions has one problem. We
> are adding a
> command to an MI protocol that can not be understood by a
> program that
> can speak a protocol. The program must,
>
> 1. Have a parser that understands the protocol it wants to speak
> (obvious and easy to get)
> 2. Have a parser that understands all future non invented protocols
> of the MI output syntax, and will be capable of parsing the current
> and future protocols to get the information it needs.
> (mostly not possible)
False inference.
> Will someone explain to me how they expect to write a parser
> capable of
> getting some information out of MI2, but prove to me that it will work
> with MI100.
Simple.
Any time anyone proposes changing the output format of the -mi-version
command, or removing it, we'll just say no. Fr'ex:
The -mi-version command will ALWAYS AND FOREVER output a string of the
format
"Highest supported MI version is XXXX"
where XXXX is an ASCII decimal integer. Any program can then read the
output from an invocation of gdb and simply discard everything up until it
finds that string, then parse the integer out.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 17:41 ` Dave Korn
@ 2004-10-06 17:55 ` 'Bob Rossi'
2004-10-06 18:19 ` Paul Koning
2004-10-07 10:56 ` Dave Korn
2004-10-06 18:43 ` Andrew Cagney
1 sibling, 2 replies; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-06 17:55 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Eli Zaretskii', gdb
On Wed, Oct 06, 2004 at 06:41:05PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: Bob Rossi [mailto:bob@brasko.net]
>
>
> > I want to make one thing clear, Eli's suggesting of making an
> > MI command
> > that returns the supported MI versions has one problem. We
> > are adding a
> > command to an MI protocol that can not be understood by a
> > program that
> > can speak a protocol. The program must,
> >
> > 1. Have a parser that understands the protocol it wants to speak
> > (obvious and easy to get)
> > 2. Have a parser that understands all future non invented protocols
> > of the MI output syntax, and will be capable of parsing the current
> > and future protocols to get the information it needs.
> > (mostly not possible)
>
> False inference.
I don't believe it's false yet.
> > Will someone explain to me how they expect to write a parser
> > capable of
> > getting some information out of MI2, but prove to me that it will work
> > with MI100.
>
> Simple.
>
> Any time anyone proposes changing the output format of the -mi-version
> command, or removing it, we'll just say no. Fr'ex:
>
> The -mi-version command will ALWAYS AND FOREVER output a string of the
> format
>
> "Highest supported MI version is XXXX"
>
> where XXXX is an ASCII decimal integer. Any program can then read the
> output from an invocation of gdb and simply discard everything up until it
> finds that string, then parse the integer out.
Unfortunatly you are only thinking of the output of the MI command. Not
the actual syntax of the MI output. This could change and you have to
deal with it.
So, to restate,
2. Have a parser that understands all future non invented protocols
of the MI output syntax, and will be capable of parsing the current
and future protocols to get the information it needs.
(mostly not possible)
Dave, can you write a piece of code that can take all of the output of
GDB, from when it starts until after it exists (only given this new MI
command), and return to me the currently supported interfaces?
Will this code work with MI5, MI6 and MI7. Since it is likely that there
will be syntax changes?
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 17:55 ` 'Bob Rossi'
@ 2004-10-06 18:19 ` Paul Koning
2004-10-07 10:56 ` Dave Korn
1 sibling, 0 replies; 212+ messages in thread
From: Paul Koning @ 2004-10-06 18:19 UTC (permalink / raw)
To: bob; +Cc: dk, eliz, gdb
>>>>> "Bob" == Bob Rossi <Bob> writes:
Bob> On Wed, Oct 06, 2004 at 06:41:05PM +0100, Dave Korn wrote:
>> > -----Original Message----- > From: Bob Rossi
>> > Will someone explain to me how they expect to write a parser >
>> capable of > getting some information out of MI2, but prove to me
>> that it will work > with MI100.
>>
>> Simple.
>>
>> Any time anyone proposes changing the output format of the
>> -mi-version command, or removing it, we'll just say no. Fr'ex:
>>
>> The -mi-version command will ALWAYS AND FOREVER output a string of
>> the format
>>
>> "Highest supported MI version is XXXX"
>>
>> where XXXX is an ASCII decimal integer. Any program can then read
>> the output from an invocation of gdb and simply discard everything
>> up until it finds that string, then parse the integer out.
Bob> Unfortunatly you are only thinking of the output of the MI
Bob> command. Not the actual syntax of the MI output. This could
Bob> change and you have to deal with it.
No, Dave is right. This is how protocol version handling is done in
protocol design practice.
The key point is this:
a. There is a well-defined way to convey the protocol version
information early on in the exchange. It may come as part of the
startup message -- if there is such a thing. Or it may be
a reply to a query that is allowed in the initial state.
b. The following items are immutable across versions:
1. The subset of parsing rules you need to find the version
data. That need not be a full parse; for example, it can
be something as simple as "the first 5 bytes of the first
message you receive". Or it might be "tag 42 of the
tag/length/value encoded payload of the first message is
the version number".
2. The query that gets you the message -- if a query is used.
So the MI evolution is constrained only enough that such a version
mechanism can be defined, and no more than that.
paul
^ permalink raw reply [flat|nested] 212+ messages in thread
* RE: probing GDB for MI versions
2004-10-06 17:55 ` 'Bob Rossi'
2004-10-06 18:19 ` Paul Koning
@ 2004-10-07 10:56 ` Dave Korn
2004-10-07 14:15 ` 'Bob Rossi'
1 sibling, 1 reply; 212+ messages in thread
From: Dave Korn @ 2004-10-07 10:56 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: 'Eli Zaretskii', gdb
> -----Original Message-----
> From: 'Bob Rossi' [mailto:bob@brasko.net]
> Sent: 06 October 2004 18:51
> Dave, can you write a piece of code that can take all of the output of
> GDB, from when it starts until after it exists (only given this new MI
> command), and return to me the currently supported interfaces?
Yes, I can, but I'm not going to do it for you. Here's a hint, in shell
terms:
echo "-mi-version" | gdb | grep "Highest supported MI version is" | ....
[you have to fill in the ... with some kind of sed or awk command]
> Will this code work with MI5, MI6 and MI7. Since it is likely
> that there will be syntax changes?
As long as the body text of that string that you blindly search for
remains the same, yes it will.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-07 10:56 ` Dave Korn
@ 2004-10-07 14:15 ` 'Bob Rossi'
2004-10-07 14:28 ` Dave Korn
0 siblings, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-07 14:15 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Eli Zaretskii', gdb
On Thu, Oct 07, 2004 at 10:04:29AM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: 'Bob Rossi' [mailto:bob@brasko.net]
> > Sent: 06 October 2004 18:51
>
> > Dave, can you write a piece of code that can take all of the output of
> > GDB, from when it starts until after it exists (only given this new MI
> > command), and return to me the currently supported interfaces?
>
> Yes, I can, but I'm not going to do it for you. Here's a hint, in shell
> terms:
>
> echo "-mi-version" | gdb | grep "Highest supported MI version is" | ....
>
> [you have to fill in the ... with some kind of sed or awk command]
>
> > Will this code work with MI5, MI6 and MI7. Since it is likely
> > that there will be syntax changes?
>
> As long as the body text of that string that you blindly search for
> remains the same, yes it will.
OK, I agree with this. Why would we add this functionality as an MI command
if the front ends all have to write some adhoc parser to get the
information?
So, I agree that it can be done, I just think it's a terrible idea.
We can do it in a much better way.
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* RE: probing GDB for MI versions
2004-10-07 14:15 ` 'Bob Rossi'
@ 2004-10-07 14:28 ` Dave Korn
2004-10-07 14:37 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Dave Korn @ 2004-10-07 14:28 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: 'Eli Zaretskii', gdb
> -----Original Message-----
> From: 'Bob Rossi'
> Sent: 07 October 2004 13:36
> > Yes, I can, but I'm not going to do it for you. Here's a
> hint, in shell
> > terms:
> >
> > echo "-mi-version" | gdb | grep "Highest supported MI
> version is" | ....
> >
> > [you have to fill in the ... with some kind of sed or awk command]
> OK, I agree with this. Why would we add this functionality as
> an MI command
> if the front ends all have to write some adhoc parser to get the
> information?
You use the term "adhoc parser" as if that were a bad thing. It's not.
It's an entirely reasonable way for a computer program to parse some data
and extract some simple information that it requires.
> So, I agree that it can be done, I just think it's a terrible idea.
> We can do it in a much better way.
This is an invalid argument. You'll have to have *some* kind of 'parsing'
going on in order to interpret the output from gdb that lists the versions
of MI, no matter whether it's an MI command or a command-line option or
anything else. So why you think one of those ways is terrible and the other
is not, on the basis of this requirement, which is in fact the same in both
cases anyway, I just don't see.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-07 14:28 ` Dave Korn
@ 2004-10-07 14:37 ` 'Bob Rossi'
2004-10-07 14:39 ` Dave Korn
0 siblings, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-07 14:37 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Eli Zaretskii', gdb
On Thu, Oct 07, 2004 at 01:48:04PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: 'Bob Rossi'
> > Sent: 07 October 2004 13:36
>
> > > Yes, I can, but I'm not going to do it for you. Here's a
> > hint, in shell
> > > terms:
> > >
> > > echo "-mi-version" | gdb | grep "Highest supported MI
> > version is" | ....
> > >
> > > [you have to fill in the ... with some kind of sed or awk command]
>
> > OK, I agree with this. Why would we add this functionality as
> > an MI command
> > if the front ends all have to write some adhoc parser to get the
> > information?
>
> You use the term "adhoc parser" as if that were a bad thing. It's not.
> It's an entirely reasonable way for a computer program to parse some data
> and extract some simple information that it requires.
You seem like you want "more of the old". GDB has come a long way from
the adhoc parsers the front end's had to generate to deal with the CLI.
The MI developers, wise as they are, decided to formalize the way GDB
output's data and front end developers parse it.
> > So, I agree that it can be done, I just think it's a terrible idea.
> > We can do it in a much better way.
>
> This is an invalid argument. You'll have to have *some* kind of 'parsing'
> going on in order to interpret the output from gdb that lists the versions
> of MI, no matter whether it's an MI command or a command-line option or
> anything else. So why you think one of those ways is terrible and the other
> is not, on the basis of this requirement, which is in fact the same in both
> cases anyway, I just don't see.
Getting the data, one line at a time, not in the context of an MI Output
command is fine with me. It has nothing to do with MI and I like that.
I have thought about this long enough to have come to a conclusion. I
think it is silly to add an MI command to GDB that can not be used by a
front end that speaks the MI protocol.
* Let's make this clear, MI commands are there for front ends that
speak the MI protocol.
The solution of adding an MI command that can only be looked at by an adhoc
parser and making rules like "the command will never change" is non-intuitive
and confusing. Having a simple mechanism, such as a command line switch or a
new interpreter, would be simple and understandable.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* RE: probing GDB for MI versions
2004-10-07 14:37 ` 'Bob Rossi'
@ 2004-10-07 14:39 ` Dave Korn
2004-10-07 14:50 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Dave Korn @ 2004-10-07 14:39 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: 'Eli Zaretskii', gdb
> -----Original Message-----
> From: 'Bob Rossi'
> Sent: 07 October 2004 15:05
[Eli, if you'd rather I Cc you out of this
now-getting-fairly-pointless-and-repetitive discussion, just drop me a note
offlist]
> > You use the term "adhoc parser" as if that were a bad
> thing. It's not.
> > It's an entirely reasonable way for a computer program to
> parse some data
> > and extract some simple information that it requires.
>
> You seem like you want "more of the old".
Don't put words in my mouth or impute motives to me, you know nothing
about me.
> GDB has come a long way from
> the adhoc parsers the front end's had to generate to deal
> with the CLI.
Your argument is a strawman.
> The MI developers, wise as they are, decided to formalize the way GDB
> output's data and front end developers parse it.
Your insistence on using formal parsers for every single job regardless of
the fact that you can also see that they're not suitable for the job flies
in the face of sanity. You're a child with a hammer and every single
problem looks to you like a nail.
> Getting the data, one line at a time, not in the context of
> an MI Output
> command is fine with me. It has nothing to do with MI and I like that.
Your rigidity and inflexibility of thought cripples your ability to apply
the appropriate tool to solve a VERY VERY SIMPLE problem. It doesn't matter
if the data is in MI format, the simple string matching approach WILL STILL
FIND IT EMBEDDED IN THE MI FORMATTING.
> I have thought about this long enough to have come to a conclusion. I
> think it is silly to add an MI command to GDB that can not be
> used by a front end that speaks the MI protocol.
Your claim is utterly false: of course the command can be used by such a
front end. The front end can use whatever means it likes to select the
correct parser for the mi version of the gdb its using, and then the output
from the -mi-versions command can be parsed by it. Just because I presented
the output as a simple plaintext string doesn't mean it shouldn't be given
in MI format, and I didn't say anything to suggest it should be, so this is
yet another strawman where you invent your own false representation of what
I've described and then attack the flaws you placed in your own invention.
> * Let's make this clear, MI commands are there for front ends that
> speak the MI protocol.
An irrelevant truism.
> The solution of adding an MI command that can only be looked
> at by an adhoc parser
As I explain above, it can also be looked at by a full MI parser.
> and making rules like "the command will never change"
> is non-intuitive and confusing.
How much experience of computer programming do you actually have? Have
you any concept of versioning mechanisms? Have you ever heard of an ABI, or
an "interface specification", in the context of it being a future guarantee?
What I describe is standard practice throughout the software industry and
has been for many many years. You need to read some books or take a course
or something. Nobody else has the conceptual difficulties you've been
getting yourself stuck in with these fundamentals.
> Having a simple mechanism, such as a command
> line switch or a
> new interpreter, would be simple and understandable.
This is still an invalid argument, for still the exact same reason that I
explained in my last post and you conveniently ignored because you had no
good answer for it. You are now just repeating yourself without adding any
new content. So I may as well repeat my explanation of the problem without
adding any new content. Please pay attention this time:
You claim that the problem is in having to supply an adhoc parser and make
rules like "the output will never change". Yet _your_ proposed solution
suffers from the exact same flaw.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-07 14:39 ` Dave Korn
@ 2004-10-07 14:50 ` 'Bob Rossi'
2004-10-07 15:38 ` Dave Korn
0 siblings, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-07 14:50 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Eli Zaretskii', gdb
> > The MI developers, wise as they are, decided to formalize the way GDB
> > output's data and front end developers parse it.
>
> Your insistence on using formal parsers for every single job regardless of
> the fact that you can also see that they're not suitable for the job flies
> in the face of sanity. You're a child with a hammer and every single
> problem looks to you like a nail.
You are inappropriate.
I clearly understand that either way an adhoc parser is involved. I
undersatnd the problem can be solved both ways, with an MI command or a
command line switch.
I understand that adding an MI command to the MI function set that can
not be accessed by a front end that understands the MI protocol is
nonsensical and confusing, that is why I am arguing on the side of not
adding this command to the MI function set, but solving the problem
another way.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* RE: probing GDB for MI versions
2004-10-07 14:50 ` 'Bob Rossi'
@ 2004-10-07 15:38 ` Dave Korn
2004-10-07 15:49 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Dave Korn @ 2004-10-07 15:38 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: gdb
> -----Original Message-----
> From: 'Bob Rossi'
> Sent: 07 October 2004 15:37
> I understand that adding an MI command to the MI function set that can
> not be accessed by a front end that understands the MI protocol is
> nonsensical and confusing
Since nobody has proposed such an addition, your opinion of it is utterly
irrelevant.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-07 15:38 ` Dave Korn
@ 2004-10-07 15:49 ` 'Bob Rossi'
2004-10-07 16:31 ` Nathan J. Williams
` (3 more replies)
0 siblings, 4 replies; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-07 15:49 UTC (permalink / raw)
To: Dave Korn; +Cc: gdb
On Thu, Oct 07, 2004 at 03:50:18PM +0100, Dave Korn wrote:
> > -----Original Message-----
> > From: 'Bob Rossi'
> > Sent: 07 October 2004 15:37
>
> > I understand that adding an MI command to the MI function set that can
> > not be accessed by a front end that understands the MI protocol is
> > nonsensical and confusing
>
> Since nobody has proposed such an addition, your opinion of it is utterly
> irrelevant.
Again, you do not understand the issue.
Adding this new function -mi-version, will be adding the first command
to the MI command set that is supposed to be used by a front end by
*not* using an MI protocol. It is confusing and non-sensical to add the
first MI command to the MI command set that can not be used by a front
end that speaks the MI protocol.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-07 15:49 ` 'Bob Rossi'
@ 2004-10-07 16:31 ` Nathan J. Williams
2004-10-07 16:45 ` Alain Magloire
` (2 subsequent siblings)
3 siblings, 0 replies; 212+ messages in thread
From: Nathan J. Williams @ 2004-10-07 16:31 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: Dave Korn, gdb
"'Bob Rossi'" <bob@brasko.net> writes:
> Adding this new function -mi-version, will be adding the first command
> to the MI command set that is supposed to be used by a front end by
> *not* using an MI protocol. It is confusing and non-sensical to add the
> first MI command to the MI command set that can not be used by a front
> end that speaks the MI protocol.
That this command is most useful to a pre-parser deciding which parser
to invoke does not mean it can't be used, or isn't useful to that
full-fledged parser. A parser whose job was validating output (in the
testsuite, say) would want to and be able to exercise it, as would a
parser that wanted to verify that it was dealing with a version of MI
it understood - and it can do that within the parse tree and formal
structure of MI.
The way you are using a parser is entirely your own choice, not
dictated by the way MI is specified; as an example, we've talked about
generated parsers and hand-written parsers for the grammar, and I'm
sure radically different approaches are also feasable. MI neural net,
anyone?
- Nathan
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-07 15:49 ` 'Bob Rossi'
2004-10-07 16:31 ` Nathan J. Williams
@ 2004-10-07 16:45 ` Alain Magloire
2004-10-07 17:12 ` Dave Korn
[not found] ` <200410071614.MAA19648@smtp.ott.qnx.com>
3 siblings, 0 replies; 212+ messages in thread
From: Alain Magloire @ 2004-10-07 16:45 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: Dave Korn, gdb
>
> On Thu, Oct 07, 2004 at 03:50:18PM +0100, Dave Korn wrote:
> > > -----Original Message-----
> > > From: 'Bob Rossi'
> > > Sent: 07 October 2004 15:37
> >
> > > I understand that adding an MI command to the MI function set that can
> > > not be accessed by a front end that understands the MI protocol is
> > > nonsensical and confusing
> >
> > Since nobody has proposed such an addition, your opinion of it is utterly
> > irrelevant.
>
> Again, you do not understand the issue.
>
> Adding this new function -mi-version, will be adding the first command
> to the MI command set that is supposed to be used by a front end by
> *not* using an MI protocol. It is confusing and non-sensical to add the
> first MI command to the MI command set that can not be used by a front
> end that speaks the MI protocol.
>
(I have this funny feeling, that you guys are going in circle !
Am I missing an important piece of the puzzle ?)
Bob, I thought I was following your way of thinking but you lost me there.
One of the reason(correct me If I'm wrong) to add -mi-version is if
the front-end start gdb like this
$ gdb -i=mi executable
Doing "-mi-version" will let the front-end adjust which parser to instanciate.
But after that, you seem to get lost on implementation details, chicken and egg
problem, with reasoning like: we need to parse the "-mi-version" with an MI parser
but wait ... we can not start the parser since we do not know yet which parser to
instanciate.
Davek's point(which I tend to agree with) is saying you need to bootstap somehow.
Let's focus for a second on this issue, from the 3 scenarios below which one
will be satisfactory for you:
1- front end starts gdb with different mi version until it finds a good one
$gdb -i=mi4 # fails
$gdb -i=mi3 # fails
$gdb -i=mi2 # sucess, start debuging
2- front end choose the protocol form the list of known
$gdb --list-protocols
3- the -mi-version
(1) looks allright and no changes is needed
(2) could be nicer
(3) is ok.
^ permalink raw reply [flat|nested] 212+ messages in thread
* RE: probing GDB for MI versions
2004-10-07 15:49 ` 'Bob Rossi'
2004-10-07 16:31 ` Nathan J. Williams
2004-10-07 16:45 ` Alain Magloire
@ 2004-10-07 17:12 ` Dave Korn
[not found] ` <200410071614.MAA19648@smtp.ott.qnx.com>
3 siblings, 0 replies; 212+ messages in thread
From: Dave Korn @ 2004-10-07 17:12 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: gdb
> -----Original Message-----
> From: 'Bob Rossi' [mailto:bob@brasko.net]
> Sent: 07 October 2004 15:55
> On Thu, Oct 07, 2004 at 03:50:18PM +0100, Dave Korn wrote:
> > > -----Original Message-----
> > > From: 'Bob Rossi'
> > > Sent: 07 October 2004 15:37
> >
> > > I understand that adding an MI command to the MI function
> set that can
> > > not be accessed by a front end that understands the MI protocol is
> > > nonsensical and confusing
> >
> > Since nobody has proposed such an addition, your opinion
> of it is utterly
> > irrelevant.
>
> Again, you do not understand the issue.
Again, you ignore the words that are actually right in front of your eyes
when you write your reply.
- I have never said what you repeatedly claim I have said.
- Therefore anything to do with that suggestion (the one which I did _NOT_
make, rather than the one which I _did_ make) is outside the current
discussion.
- I do not need to address anything that is outside the current
discussion.
- Therefore I have no need to "understand the issue" in question.
[Entire paragraph's-worth of sarcasm removed after thinking better of it
here. See, I am _trying_ to be reasonable. Shame though, some of it was
quite cutting and witty.]
> Adding this new function -mi-version, will be adding the
> first command
> to the MI command set that is supposed to be used by a front end by
> *not* using an MI protocol.
This is an entirely arbitrary claim which you appear to have just
invented. I never suggested such a thing. Please stop tilting at strawmen.
> It is confusing and non-sensical
> to add the
> first MI command to the MI command set that can not be used
> by a front
> end that speaks the MI protocol.
If you're going to abuse the meaning of the words "can not" like that, we
aren't even speaking the same language. There's *nothing* about the
"-mi-version" command that prevents it from being "used by a front end that
speaks the MI protocol". It *can* be used, and in *exactly* the same way as
it would send *any* other MI command and parse the reply. So your sentence
should have said "can" where it currently says "can not", at least if you
wanted it to be correct.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 212+ messages in thread
[parent not found: <200410071614.MAA19648@smtp.ott.qnx.com>]
* Re: probing GDB for MI versions
[not found] ` <200410071614.MAA19648@smtp.ott.qnx.com>
@ 2004-10-08 6:56 ` 'Bob Rossi'
2004-10-08 9:10 ` Eli Zaretskii
0 siblings, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-08 6:56 UTC (permalink / raw)
To: Alain Magloire; +Cc: Dave Korn, gdb
On Thu, Oct 07, 2004 at 12:14:00PM -0400, Alain Magloire wrote:
> >
> > On Thu, Oct 07, 2004 at 03:50:18PM +0100, Dave Korn wrote:
> > > > -----Original Message-----
> > > > From: 'Bob Rossi'
> > > > Sent: 07 October 2004 15:37
> > >
> > > > I understand that adding an MI command to the MI function set that can
> > > > not be accessed by a front end that understands the MI protocol is
> > > > nonsensical and confusing
> > >
> > > Since nobody has proposed such an addition, your opinion of it is utterly
> > > irrelevant.
> >
> > Again, you do not understand the issue.
> >
> > Adding this new function -mi-version, will be adding the first command
> > to the MI command set that is supposed to be used by a front end by
> > *not* using an MI protocol. It is confusing and non-sensical to add the
> > first MI command to the MI command set that can not be used by a front
> > end that speaks the MI protocol.
> >
>
> (I have this funny feeling, that you guys are going in circle !
> Am I missing an important piece of the puzzle ?)
>
> Bob, I thought I was following your way of thinking but you lost me there.
> One of the reason(correct me If I'm wrong) to add -mi-version is if
> the front-end start gdb like this
> $ gdb -i=mi executable
>
> Doing "-mi-version" will let the front-end adjust which parser to instanciate.
Yes, asking GDB what version is supports allows the front end to chose a
parser that can handle the MI protocol.
> But after that, you seem to get lost on implementation details, chicken and egg
> problem, with reasoning like: we need to parse the "-mi-version" with an MI parser
> but wait ... we can not start the parser since we do not know yet which parser to
> instanciate.
Yes.
> Davek's point(which I tend to agree with) is saying you need to bootstap somehow.
Yes, you need to bootstrap, I agree.
> Let's focus for a second on this issue, from the 3 scenarios below which one
> will be satisfactory for you:
>
> 1- front end starts gdb with different mi version until it finds a good one
> $gdb -i=mi4 # fails
> $gdb -i=mi3 # fails
> $gdb -i=mi2 # sucess, start debuging
This is possible, yet is obviously ugly. Imagine MI 1000 :)
Also, GDB starts up it's development version of MI when you ask it to.
> 2- front end choose the protocol form the list of known
> $gdb --list-protocols
I like this solution.
However, I understand that not everyone does and I can see why.
> 3- the -mi-version
I do not like this solution. I do not like adding an MI command to the
MI function set that is not intended to be parsed by a front end that
can speak the MI protocol. I've stated that this is confusing and
nonsensical.
I understand that the new mi command could be called by a front end that
speaks the MI protocol, but only after the front end new which MI
protocol to speak. The front end would have to come up with an adhoc
parser for getting the information that it needs, and this would be the
first and only MI command that has to be used like this.
Finally, there are several other solutions,
* An interpreter that only outputs the mi versions
* A handshaking protocol
* Have GDB output it's last stable version of MI as the first thing
it outputs (subset of case above)
Thanks,
Bob Rossi
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-08 6:56 ` 'Bob Rossi'
@ 2004-10-08 9:10 ` Eli Zaretskii
2004-10-10 18:13 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-08 9:10 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: gdb
> Date: Thu, 7 Oct 2004 18:42:30 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: Dave Korn <dk@artimi.com>, gdb@sources.redhat.com
>
> * Have GDB output it's last stable version of MI as the first thing
> it outputs (subset of case above)
Will this solution be satisfactory for you? That is, when invoked
with the -interpreter=mi<N> command-line switch, GDB will print the
last stable version of the MI protocol it supports. This is actually
the way many protocol negotiations start, and I don't see why we
shouldn't behave the same.
Note that a front end which wants to support older GDB versions will
need to have a database of MI versions referenced by GDB versions,
because the old GDB versions will not print the MI version.
Are there any disadvantages to this solution?
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-08 9:10 ` Eli Zaretskii
@ 2004-10-10 18:13 ` 'Bob Rossi'
2004-10-11 17:46 ` 'Bob Rossi'
2004-10-13 12:14 ` 'Bob Rossi'
0 siblings, 2 replies; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-10 18:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
On Fri, Oct 08, 2004 at 10:36:45AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 7 Oct 2004 18:42:30 -0400
> > From: 'Bob Rossi' <bob@brasko.net>
> > Cc: Dave Korn <dk@artimi.com>, gdb@sources.redhat.com
> >
> > * Have GDB output it's last stable version of MI as the first thing
> > it outputs (subset of case above)
>
> Will this solution be satisfactory for you? That is, when invoked
> with the -interpreter=mi<N> command-line switch, GDB will print the
> last stable version of the MI protocol it supports. This is actually
> the way many protocol negotiations start, and I don't see why we
> shouldn't behave the same.
>
> Note that a front end which wants to support older GDB versions will
> need to have a database of MI versions referenced by GDB versions,
> because the old GDB versions will not print the MI version.
>
> Are there any disadvantages to this solution?
Sorry for the delay, I am waiting on the answer for these questions
http://sources.redhat.com/ml/gdb/2004-10/msg00267.html
before I can say if this will be OK for me.
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-10 18:13 ` 'Bob Rossi'
@ 2004-10-11 17:46 ` 'Bob Rossi'
2004-10-13 12:14 ` 'Bob Rossi'
1 sibling, 0 replies; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-11 17:46 UTC (permalink / raw)
To: Eli Zaretskii, gdb
On Fri, Oct 08, 2004 at 08:29:01PM -0400, 'Bob Rossi' wrote:
> On Fri, Oct 08, 2004 at 10:36:45AM +0200, Eli Zaretskii wrote:
> > > Date: Thu, 7 Oct 2004 18:42:30 -0400
> > > From: 'Bob Rossi' <bob@brasko.net>
> > > Cc: Dave Korn <dk@artimi.com>, gdb@sources.redhat.com
> > >
> > > * Have GDB output it's last stable version of MI as the first thing
> > > it outputs (subset of case above)
> >
> > Will this solution be satisfactory for you? That is, when invoked
> > with the -interpreter=mi<N> command-line switch, GDB will print the
> > last stable version of the MI protocol it supports. This is actually
> > the way many protocol negotiations start, and I don't see why we
> > shouldn't behave the same.
> >
> > Note that a front end which wants to support older GDB versions will
> > need to have a database of MI versions referenced by GDB versions,
> > because the old GDB versions will not print the MI version.
> >
> > Are there any disadvantages to this solution?
>
> Sorry for the delay, I am waiting on the answer for these questions
> http://sources.redhat.com/ml/gdb/2004-10/msg00267.html
> before I can say if this will be OK for me.
>
> Bob Rossi
OK, I have received an answer. Basically GDB has already, and may in the
future support multiple versions of MI. The solution above is perfect if
GDB supports one stable version of MI, however, if it supports multiple
versions of MI, the front end still needs to tell GDB which version it
wants to use.
I have come up with a crude patch that makes GDB work like this,
the '>' means that GDB is outputting data to the front end, and the '<'
means that GDB is inputting data from the front end.
$ ./gdb -i=mi-handshake
>mi1
>mi2
>mi3
<mi2
>~"GNU gdb 6.2.50_2004-10-08-cvs\n"
>...
>(gdb)
Basically, just to get the idea, GDB outputs all of the MI front end's
that it supports, and then allows the front end to choose one. All of
this happens before GDB initializes the interpreter, so that after the
choice is made, GDB does not have to be restarted and will work with the
protocol selected by the front end.
Any ideas?
Obviously we could define the handshaking better, and allow for
development vs stable releases to be made clear. Also, make room for
future extensions and make a grammar, ..
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-10 18:13 ` 'Bob Rossi'
2004-10-11 17:46 ` 'Bob Rossi'
@ 2004-10-13 12:14 ` 'Bob Rossi'
2004-10-13 12:48 ` Eli Zaretskii
1 sibling, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-13 12:14 UTC (permalink / raw)
To: Eli Zaretskii, gdb
On Fri, Oct 08, 2004 at 08:29:01PM -0400, 'Bob Rossi' wrote:
> On Fri, Oct 08, 2004 at 10:36:45AM +0200, Eli Zaretskii wrote:
> > > Date: Thu, 7 Oct 2004 18:42:30 -0400
> > > From: 'Bob Rossi' <bob@brasko.net>
> > > Cc: Dave Korn <dk@artimi.com>, gdb@sources.redhat.com
> > >
> > > * Have GDB output it's last stable version of MI as the first thing
> > > it outputs (subset of case above)
> >
> > Will this solution be satisfactory for you? That is, when invoked
> > with the -interpreter=mi<N> command-line switch, GDB will print the
> > last stable version of the MI protocol it supports. This is actually
> > the way many protocol negotiations start, and I don't see why we
> > shouldn't behave the same.
> >
> > Note that a front end which wants to support older GDB versions will
> > need to have a database of MI versions referenced by GDB versions,
> > because the old GDB versions will not print the MI version.
> >
> > Are there any disadvantages to this solution?
>
> Sorry for the delay, I am waiting on the answer for these questions
> http://sources.redhat.com/ml/gdb/2004-10/msg00267.html
> before I can say if this will be OK for me.
Let's start smaller, everyone seems to be happy with the handshaking
idea. Any objections?
With this idea there are 2 alternatives I can think of.
* put the handshaking under a different interpreter (-i=mi-handshake)
* integrate the handshaking as part of the MI protocol (version 3 and on)
I kind of prefer having to call the mi-handshake interpreter explicitly,
and not making it part of the MI protocol. This way, if a front end
wants to start mi3 or any other protocol, they can explicitly state it.
For example, gdb -i=mi3 will start MI protocol version 3 like it always
has. There should be no handshaking involved if the front end selects a
specific version. If a front end wants to go into handshaking mode to
select a protocol, it can explicitly ask to do so. (gdb -i=mi-handshake)
This is the solution to the problem that I would like to implement, any
objections?
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-13 12:14 ` 'Bob Rossi'
@ 2004-10-13 12:48 ` Eli Zaretskii
2004-10-13 14:05 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-13 12:48 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: gdb
> Date: Tue, 12 Oct 2004 20:31:35 -0400
> From: 'Bob Rossi' <bob@brasko.net>
>
> With this idea there are 2 alternatives I can think of.
> * put the handshaking under a different interpreter (-i=mi-handshake)
> * integrate the handshaking as part of the MI protocol (version 3 and on)
What's wrong with a simpler idea already suggested here: that GDB will
output the MI version as part of the starting blurb when invoked with
"-interpreter=mi" option?
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-13 12:48 ` Eli Zaretskii
@ 2004-10-13 14:05 ` 'Bob Rossi'
2004-10-14 7:10 ` Eli Zaretskii
0 siblings, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-13 14:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
On Wed, Oct 13, 2004 at 06:47:37AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 12 Oct 2004 20:31:35 -0400
> > From: 'Bob Rossi' <bob@brasko.net>
> >
> > With this idea there are 2 alternatives I can think of.
> > * put the handshaking under a different interpreter (-i=mi-handshake)
> > * integrate the handshaking as part of the MI protocol (version 3 and on)
>
> What's wrong with a simpler idea already suggested here: that GDB will
> output the MI version as part of the starting blurb when invoked with
> "-interpreter=mi" option?
That method is fine if GDB supports only one stable MI protocol at a
time. However, I have been told that GDB will support multiple versions
of MI at a time.
If GDB supported only one stable MI version at a time, then it could
just do what you are saying, tell the front end what version it is going
to output. This is basically how XML and HTML documents work. The first
line is the version of the file, and the client reads that and uses the
appropriate parser.
However, GDB is not that simple. It can support several versions of the
MI protocol. Some of the versions can be developmental, others can be
stable, and others can be unstable. For instance, the current GDB has
mi2 being stable, and mi1 being unstable (not tested). For this reason,
GDB and the front end actually need to handshake to determine what
protocol should be used. I'm assuming that this is more like the
Ethernet example someone brought up were all of the devices have to
query each other to figure out what protocol to use.
Here is something I came up with last night,
GDB/MI Handshaking output
mi-handshake-input => mi-protocol-output [ "," mi-protocol-output ]* nl
mi-protocol-output => mi-protocol-class "=" mi-protocol
mi-protocol-class => "mi_unsupported" | "mi_supported" | "mi_development"
mi-protocol => "mi" digit
digit => 1 | 1 + digit
nl => CR | CR NL | NL
GDB/MI Handshaking input
mi-handshake-input => mi-protocol nl
Obviously, that results in GDB outputting something like,
mi_unsupported=mi1,mi_supported=mi2,mi_development=mi3
and the front end sending to GDB simply "mi2".
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-13 14:05 ` 'Bob Rossi'
@ 2004-10-14 7:10 ` Eli Zaretskii
2004-10-14 19:34 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-14 7:10 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: gdb
> Date: Wed, 13 Oct 2004 08:14:12 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: gdb@sources.redhat.com
>
> > What's wrong with a simpler idea already suggested here: that GDB will
> > output the MI version as part of the starting blurb when invoked with
> > "-interpreter=mi" option?
>
> That method is fine if GDB supports only one stable MI protocol at a
> time. However, I have been told that GDB will support multiple versions
> of MI at a time.
Yes, but Andrew just told you that GDB will most probably support at
most 2 MI versions: the latest one and the one before that. So
printing only the last version is okay, because if that version is not
supported by your front end, you need only to check the previous
version. Isn't that good enough?
(Even if GDB does support more than 2 MI versions, you could still
probe smaller versions until you either (1) find one that is okay with
your front end, or (2) get GDB to fail because the MI version you
requested is not supported.
And if that is still not good enough, let's have GDB output a list of
supported MI versions as part of its starting blurb, e.g. one version
per line.
Will that finally put this issue to rest?
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-14 7:10 ` Eli Zaretskii
@ 2004-10-14 19:34 ` 'Bob Rossi'
2004-10-14 21:23 ` Andrew Cagney
2004-10-15 13:02 ` Eli Zaretskii
0 siblings, 2 replies; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-14 19:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
On Wed, Oct 13, 2004 at 10:29:31PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 13 Oct 2004 08:14:12 -0400
> > From: 'Bob Rossi' <bob@brasko.net>
> > Cc: gdb@sources.redhat.com
> >
> > > What's wrong with a simpler idea already suggested here: that GDB will
> > > output the MI version as part of the starting blurb when invoked with
> > > "-interpreter=mi" option?
> >
> > That method is fine if GDB supports only one stable MI protocol at a
> > time. However, I have been told that GDB will support multiple versions
> > of MI at a time.
>
> Yes, but Andrew just told you that GDB will most probably support at
> most 2 MI versions: the latest one and the one before that. So
> printing only the last version is okay, because if that version is not
> supported by your front end, you need only to check the previous
> version. Isn't that good enough?
>
> (Even if GDB does support more than 2 MI versions, you could still
> probe smaller versions until you either (1) find one that is okay with
> your front end, or (2) get GDB to fail because the MI version you
> requested is not supported.
I can give several reasons why this is not good enough. As far as I can
tell, there are 3 types of MI protocols. Supported, unsupported and
developmental. This information needs to be given to the front end. For
example, right now GDB supports MI2. However, if a front end understood
only MI1, then it would be tempted to try MI1 with your approach.
However, MI1 is unsupported and most likely doesn't work. It would be
nice if the front end was capable of understanding that.
> And if that is still not good enough, let's have GDB output a list of
> supported MI versions as part of its starting blurb, e.g. one version
> per line.
This seems reasonable. There are 2 down sides that I don't like
* There is no handshaking being done. Average case scenario is starting
GDB twice to get it into the correct mode. Once to find out the
supported versions, second to start it in the correct mode.
* It tells the front end only the minimum information it needs to
know. (developmental and unsupported interfaces are not printed)
Again, this probably isn't to important.
If we implement the handshaking solution that I had, it is guaranteed that
the front end will be able to start GDB only once and get it into the
correct MI protocol.
What is wrong with the handshaking protocol that I described? I see it
as the optimal solution and would be happy to implement it.
> Will that finally put this issue to rest?
I understand this issue is long and drawn out, however, it is critical
for a front end to GDB that plans on working with multiple GDB's and
not just one that is bundled together.
Thanks for helping out!
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-14 19:34 ` 'Bob Rossi'
@ 2004-10-14 21:23 ` Andrew Cagney
2004-10-15 15:40 ` 'Bob Rossi'
2004-10-15 13:02 ` Eli Zaretskii
1 sibling, 1 reply; 212+ messages in thread
From: Andrew Cagney @ 2004-10-14 21:23 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: Eli Zaretskii, gdb
>>> Yes, but Andrew just told you that GDB will most probably support at
>>> most 2 MI versions: the latest one and the one before that. So
>>> printing only the last version is okay, because if that version is not
>>> supported by your front end, you need only to check the previous
>>> version. Isn't that good enough?
>>>
>>> (Even if GDB does support more than 2 MI versions, you could still
>>> probe smaller versions until you either (1) find one that is okay with
>>> your front end, or (2) get GDB to fail because the MI version you
>>> requested is not supported.
Yes, it's good enough. Either:
- GDB is started with -i=mi; gdb reports its version (if anything I'd be
relying on the GDB and not the MI version); your code adjusts
- GDB is started with -i=miX; gdb either barfs or soldiers on; your code
adjusts
Andrew
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-14 21:23 ` Andrew Cagney
@ 2004-10-15 15:40 ` 'Bob Rossi'
0 siblings, 0 replies; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-15 15:40 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Eli Zaretskii, gdb
On Thu, Oct 14, 2004 at 02:53:29PM -0400, Andrew Cagney wrote:
>
> >>>Yes, but Andrew just told you that GDB will most probably support at
> >>>most 2 MI versions: the latest one and the one before that. So
> >>>printing only the last version is okay, because if that version is not
> >>>supported by your front end, you need only to check the previous
> >>>version. Isn't that good enough?
> >>>
> >>>(Even if GDB does support more than 2 MI versions, you could still
> >>>probe smaller versions until you either (1) find one that is okay with
> >>>your front end, or (2) get GDB to fail because the MI version you
> >>>requested is not supported.
>
> Yes, it's good enough. Either:
>
> - GDB is started with -i=mi; gdb reports its version (if anything I'd be
> relying on the GDB and not the MI version); your code adjusts
This case does not make sense for the task I am hoping to accomplish.
It does not allow the front end to figure out what tested versions of
the MI protocol a particular GDB supports.
The only thing this does is tell the front end what version of MI that
GDB will be speaking. This is necesary but it is a different problem
than I am trying to solve.
If you added this to the MI protocol, which I think it should be, it
still does not solve the problem of finding out what tested versions of
the MI protocol GDB supports.
> - GDB is started with -i=miX; gdb either barfs or soldiers on; your code
> adjusts
Yes, this case makes sense. I am not interested in the case were the
user asks for a particular version of the MI protocol.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-14 19:34 ` 'Bob Rossi'
2004-10-14 21:23 ` Andrew Cagney
@ 2004-10-15 13:02 ` Eli Zaretskii
2004-10-15 13:28 ` Michael Chastain
2004-10-15 18:04 ` 'Bob Rossi'
1 sibling, 2 replies; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-15 13:02 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: gdb
> Date: Thu, 14 Oct 2004 11:37:20 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: gdb@sources.redhat.com
>
> > Yes, but Andrew just told you that GDB will most probably support at
> > most 2 MI versions: the latest one and the one before that. So
> > printing only the last version is okay, because if that version is not
> > supported by your front end, you need only to check the previous
> > version. Isn't that good enough?
> >
> > (Even if GDB does support more than 2 MI versions, you could still
> > probe smaller versions until you either (1) find one that is okay with
> > your front end, or (2) get GDB to fail because the MI version you
> > requested is not supported.
>
> I can give several reasons why this is not good enough. As far as I can
> tell, there are 3 types of MI protocols. Supported, unsupported and
> developmental.
I was only talking about stable versions, so developmental is not
something we should consider (we've been through this and decided that
it is unsafe to use such versions).
> This information needs to be given to the front end. For
> example, right now GDB supports MI2. However, if a front end understood
> only MI1, then it would be tempted to try MI1 with your approach.
> However, MI1 is unsupported and most likely doesn't work.
If MI1 is not working and the front end only supports MI1, then this
combination of GDB and front end is not going to work. So I submit
that this case is not interesting: you will try MI1 and things will go
wrong at some point.
However, ``unsupported'' and ``doesn't work'' are not the same thing.
If we know that a certain version of MI does not work, we should
remove its support from GDB. If we didn't do that, then we have good
reasons to believe that MI1 does in fact work.
> It would be
> nice if the front end was capable of understanding that.
And then do what? print a message "like unsupported GDB version"? Is
this really an interesting case? I thought you were interested in
getting a front end to _work_ with MI; graceful failure is something
different. Can we please solve one problem at a time? Do you agree
that if either (1) the front end supports the latest stable version or
(2) the version before that works reasonably well, then printing only
the latest stable version at startup is good enough?
> This seems reasonable. There are 2 down sides that I don't like
>
> * There is no handshaking being done. Average case scenario is starting
> GDB twice to get it into the correct mode. Once to find out the
> supported versions, second to start it in the correct mode.
I don't see this as a grave problem.
> * It tells the front end only the minimum information it needs to
> know. (developmental and unsupported interfaces are not printed)
> Again, this probably isn't to important.
Indeed.
> What is wrong with the handshaking protocol that I described?
It is too complicated for the job, IMHO.
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-15 13:02 ` Eli Zaretskii
@ 2004-10-15 13:28 ` Michael Chastain
2004-10-15 13:42 ` Eli Zaretskii
2004-10-15 18:04 ` 'Bob Rossi'
1 sibling, 1 reply; 212+ messages in thread
From: Michael Chastain @ 2004-10-15 13:28 UTC (permalink / raw)
To: eliz, bob; +Cc: gdb
gcc has many options with similar purposes:
-print-file-name=LIBRARY
Print the full absolute name of the library file LIBRARY
that would be used when linking--and don't do anything else.
With this option, GCC does not compile or link anything;
it just prints the file name.
-print-multi-directory
Print the directory name corresponding to the multilib selected
by any other switches present in the command line. [et cetera]
-print-multi-lib
Print the mapping from multilib directory names to compiler
switches that enable them. [et cetera]
-print-prog-name=PROGRAM
Like -print-file-name, but searches for a program such as cpp.
-print-libgcc-file-name
[et cetera]
-print-search-dirs
[et cetera]
-dumpmachine
-dumpversion
-dumpspecs
[et cetera]
This situation looks very similar. So if -print-XXX and --dumpYYY
are working well for gcc, then "gdb -print-mi-versions" ought to
be fine. Like Bob, I don't have a problem with invoking gdb twice.
Just my two cents,
Michael
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-15 13:02 ` Eli Zaretskii
2004-10-15 13:28 ` Michael Chastain
@ 2004-10-15 18:04 ` 'Bob Rossi'
2004-10-16 15:46 ` Eli Zaretskii
1 sibling, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-15 18:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
> I was only talking about stable versions, so developmental is not
> something we should consider (we've been through this and decided that
> it is unsafe to use such versions).
Yes, you are correct.
> > This information needs to be given to the front end. For
> > example, right now GDB supports MI2. However, if a front end understood
> > only MI1, then it would be tempted to try MI1 with your approach.
> > However, MI1 is unsupported and most likely doesn't work.
>
> If MI1 is not working and the front end only supports MI1, then this
> combination of GDB and front end is not going to work. So I submit
> that this case is not interesting: you will try MI1 and things will go
> wrong at some point.
>
> However, ``unsupported'' and ``doesn't work'' are not the same thing.
> If we know that a certain version of MI does not work, we should
> remove its support from GDB. If we didn't do that, then we have good
> reasons to believe that MI1 does in fact work.
I think that supported(tested) and unsupported(untested) are two
entirely different things. Users should not be responsible for finding
bugs in the MI protocol because GDB said that a front end could use a
depricated protocol. It's just not fair. Also, above and beyond that, I
do not want my front end to work with untested versions of the MI
protocol, it would simply make me look bad when things stopped working
half way throuh a session.
> > It would be
> > nice if the front end was capable of understanding that.
>
> And then do what? print a message "like unsupported GDB version"? Is
> this really an interesting case?
I consider this a very interesting case.
> I thought you were interested in
> getting a front end to _work_ with MI; graceful failure is something
> different. Can we please solve one problem at a time? Do you agree
> that if either (1) the front end supports the latest stable version or
> (2) the version before that works reasonably well, then printing only
> the latest stable version at startup is good enough?
No, I can not agree to that. Again, like I said to andrew, printing the
latest stable version simply is common sense. It allows the front end to
determine if it can work with the current GDB. It is a different problem
than probing GDB to determine what MI versions that it supports.
Especially the second case that you have posted makes no sense to me,
"the version before works reasonably well". I don't want a reasonably
well working verion, I want a version that it tested in the testsuite.
> > This seems reasonable. There are 2 down sides that I don't like
> >
> > * There is no handshaking being done. Average case scenario is starting
> > GDB twice to get it into the correct mode. Once to find out the
> > supported versions, second to start it in the correct mode.
>
> I don't see this as a grave problem.
>
> > * It tells the front end only the minimum information it needs to
> > know. (developmental and unsupported interfaces are not printed)
> > Again, this probably isn't to important.
>
> Indeed.
>
> > What is wrong with the handshaking protocol that I described?
>
> It is too complicated for the job, IMHO.
Can I sum up the solutions we have, because it's obvious that we are not
interested in solving the problem the same way. You and I are on the
opposite side of each different type of solution that we come up with
and this is why it is taking a very long time to reach a middle point.
* printing just the latest stable version
Is this the version that GDB will start up in if you do -i=mi even if
you are using a CVS snapshot and the version has been bumped?
This solution is lacking. It only tells the front end the latest
stable version of the MI protocol. The front end can only guess what
other stable versions are available and I consider this unacceptable.
For CVS snapshots, if the above questions is true, then it will
always print out the latest stable version and it will be
communicating not in that version. This requires a restart no matter
what.
This does not satisfy the minimum amount of information that I need.
* printing all of the tested MI versions.
This solution is basically my 'command line switch' solution.
This is the minimum information that I need. A front end that
wants to work with GDB will need to know every version of the MI
protocol that the particular GDB was tested with.
However, this solution requires starting GDB twice, which I would not
prefer if it was solvable with just starting it once.
* creating a handshaking protocol
This is the optimal solution since it gives the front end all of the
tested MI versions and then allows the front end to select which
version GDB should use. This is the solution I prefer. It requires
GDB asking the front end for the version, and the other solutions do
not require this.
It could be as simple as outputting all of the tested MI versions one
line at a time and then allowing the front end to select one or it
could be more complicated like the grammar that I posted earlier.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-15 18:04 ` 'Bob Rossi'
@ 2004-10-16 15:46 ` Eli Zaretskii
2004-10-16 21:56 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-16 15:46 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: gdb
> Date: Fri, 15 Oct 2004 11:40:17 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: gdb@sources.redhat.com
>
> I think that supported(tested) and unsupported(untested) are two
> entirely different things.
Not entirely: an MI version does not become buggy just because you
stop testing it. The bit-rotting process takes time, and during that
time the untested MI is still working reasonably well.
Also, the fact that something is tested does not mean there are no
bugs in it.
So let's stop talking about absolutes because they are not appropriate
here. Let's keep the discussion focused on practical problems, not on
principles.
> > > It would be
> > > nice if the front end was capable of understanding that.
> >
> > And then do what? print a message "like unsupported GDB version"? Is
> > this really an interesting case?
>
> I consider this a very interesting case.
More interesting than the case where the front end _can_ find a
working MI version?
> I don't want a reasonably well working verion, I want a version that
> it tested in the testsuite.
Then you must make sure your front end supports the latest stable
version, and only that version, and this whole discussion is mostly
irrelevant, because just printing the latest stable version is all you
need (if the front end doesn't support that version, it should refuse
to work). See below.
> * printing just the latest stable version
>
> Is this the version that GDB will start up in if you do -i=mi even if
> you are using a CVS snapshot and the version has been bumped?
No. The latest stable version is not the one that is invoked with
"-i=mi", it is the stable version before that.
> This solution is lacking. It only tells the front end the latest
> stable version of the MI protocol. The front end can only guess what
> other stable versions are available and I consider this unacceptable.
According to what Andrew said, and since you don't want to use
untested old versions, the latest stable version is all you need.
> However, this solution requires starting GDB twice, which I would not
> prefer if it was solvable with just starting it once.
I don't see any problem in restart, if that is indeed required.
However, it sounds like a restart will not be needed, since the front
end supports only one version: the latest stable one.
Again, if you are unprepared to work with any MI version but the ones
that are actively tested by the testsuite, then your front end will
need constant work to make it support the latest stable version, and
it should refuse to work with any other version.
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-16 15:46 ` Eli Zaretskii
@ 2004-10-16 21:56 ` 'Bob Rossi'
2004-10-17 18:59 ` Eli Zaretskii
0 siblings, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-16 21:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
> > I don't want a reasonably well working verion, I want a version that
> > it tested in the testsuite.
>
> Then you must make sure your front end supports the latest stable
> version, and only that version, and this whole discussion is mostly
> irrelevant, because just printing the latest stable version is all you
> need (if the front end doesn't support that version, it should refuse
> to work). See below.
OK, here's where I think you and I are not on the same level. This is
the fundamental problem in our discussion and why we can not agree on a
solution. Please correct me if I'm wrong here.
You think that GDB does and will only test one version of the MI
protocol. If this is true, then I would be happy to implement your
solution of printing the latest stable version and starting that version
with -i=mi. This conversation could be over with :)
However, as far as I understand it, this is not true. GDB has, and in
the future could be shipped with several versions of the MI protocol
being tested. Here is the question and answer I got from Andrew,
* Will GDB support more than one stable MI protocols for an official release?
In the past GDB tested both mi1 and mi2 so that that stage they were
probably described as "supported". Now that only mi2 is tested, nad mi1 is
deprecated, your call.
With this in mind, I do not think it is OK to print the latest stable
version only. It does not tell the front end what other versions could
be stable. In order for a front end to determine the protocol to use, it
needs a list of all the tested MI protocols. After that, selecting the
appropriate protocol seems like a nice thing to allow front ends to do,
thus not having to restart GDB. This seems like a natural extension to
the MI protocol and IMHO should have been around from the start.
If there indeed is more than one tested version of the MI protocol,
would you agree to me implementing the handshaking protocol? or are you
against that either way?
> > This solution is lacking. It only tells the front end the latest
> > stable version of the MI protocol. The front end can only guess what
> > other stable versions are available and I consider this unacceptable.
>
> According to what Andrew said, and since you don't want to use
> untested old versions, the latest stable version is all you need.
I posted the Q/A above that makes me think that what you are saying here
is not correct. However, please do correct me if I'm wrong.
Thanks for your time,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-16 21:56 ` 'Bob Rossi'
@ 2004-10-17 18:59 ` Eli Zaretskii
2004-10-19 13:51 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-17 18:59 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: gdb
> Date: Sat, 16 Oct 2004 11:46:11 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: gdb@sources.redhat.com
>
> You think that GDB does and will only test one version of the MI
> protocol.
It's not what I think, it's what Andrew said was the policy.
> * Will GDB support more than one stable MI protocols for an official release?
> In the past GDB tested both mi1 and mi2 so that that stage they were
> probably described as "supported". Now that only mi2 is tested, nad mi1 is
> deprecated, your call.
>
> With this in mind, I do not think it is OK to print the latest stable
> version only. It does not tell the front end what other versions could
> be stable.
IIRC, MI1's tests were removed from the CVS as soon as MI2 was deemed
stable enough. So this example doesn't conflict with what I said.
Anyway, I already suggested to have a list of versions printed at
startup time, if you still think several tested versions of MI will be
available. We seem to go in circles since then.
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-17 18:59 ` Eli Zaretskii
@ 2004-10-19 13:51 ` 'Bob Rossi'
2004-10-19 14:18 ` Daniel Jacobowitz
0 siblings, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-19 13:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
On Sat, Oct 16, 2004 at 07:41:32PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 16 Oct 2004 11:46:11 -0400
> > From: 'Bob Rossi' <bob@brasko.net>
> > Cc: gdb@sources.redhat.com
> >
> > You think that GDB does and will only test one version of the MI
> > protocol.
>
> It's not what I think, it's what Andrew said was the policy.
He did? I thought he said "who knows", meaning he didn't know. How could
he create policy on this if he doesn't know.
>>> * Will GDB support more than one stable MI protocols for a CVS
>>> snapshot?
Who knows,
> > * Will GDB support more than one stable MI protocols for an official release?
> > In the past GDB tested both mi1 and mi2 so that that stage they were
> > probably described as "supported". Now that only mi2 is tested, nad mi1 is
> > deprecated, your call.
> >
> > With this in mind, I do not think it is OK to print the latest stable
> > version only. It does not tell the front end what other versions could
> > be stable.
>
> IIRC, MI1's tests were removed from the CVS as soon as MI2 was deemed
> stable enough. So this example doesn't conflict with what I said.
>
> Anyway, I already suggested to have a list of versions printed at
> startup time, if you still think several tested versions of MI will be
> available. We seem to go in circles since then.
Yes, I understand.
If GDB is going to support 1 stable version of the MI protocol at a time
then just have it print the version on startup. There is no negotiation
that needs to take place.
If GDB is going to support multiple stable versions of the MI protocol
at a time, then have it print all of the versions like you suggested.
Also, above what you suggested, I think the front end should be able to
select the version it wants from the list. Is this OK?
I'd like to work on this patch as soon as possible, so that I can start
using it. Is the multiple stable version approach with negotiation OK?
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-19 13:51 ` 'Bob Rossi'
@ 2004-10-19 14:18 ` Daniel Jacobowitz
2004-10-19 19:28 ` Bob Rossi
2004-10-19 20:17 ` Eli Zaretskii
0 siblings, 2 replies; 212+ messages in thread
From: Daniel Jacobowitz @ 2004-10-19 14:18 UTC (permalink / raw)
To: Eli Zaretskii, gdb
On Tue, Oct 19, 2004 at 09:19:53AM -0400, 'Bob Rossi' wrote:
> Yes, I understand.
>
> If GDB is going to support 1 stable version of the MI protocol at a time
> then just have it print the version on startup. There is no negotiation
> that needs to take place.
>
> If GDB is going to support multiple stable versions of the MI protocol
> at a time, then have it print all of the versions like you suggested.
> Also, above what you suggested, I think the front end should be able to
> select the version it wants from the list. Is this OK?
>
> I'd like to work on this patch as soon as possible, so that I can start
> using it. Is the multiple stable version approach with negotiation OK?
I think it's pretty clear that no one else likes the idea of
negotiating. I certainly don't.
I believe that printing the latest stable version of MI is plenty
adequate. If the front end wants a development version of MI it can
use -i=mi; if it wants the latest stable version it can use that
version; if it does not recognize that version it can use the latest
version it recognizes. If you encounter a situation in which that
version no longer works, have it removed from GDB.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-19 14:18 ` Daniel Jacobowitz
@ 2004-10-19 19:28 ` Bob Rossi
2004-10-19 20:17 ` Eli Zaretskii
1 sibling, 0 replies; 212+ messages in thread
From: Bob Rossi @ 2004-10-19 19:28 UTC (permalink / raw)
To: Eli Zaretskii, gdb
On Tue, Oct 19, 2004 at 09:28:24AM -0400, Daniel Jacobowitz wrote:
> On Tue, Oct 19, 2004 at 09:19:53AM -0400, 'Bob Rossi' wrote:
> > Yes, I understand.
> >
> > If GDB is going to support 1 stable version of the MI protocol at a time
> > then just have it print the version on startup. There is no negotiation
> > that needs to take place.
> >
> > If GDB is going to support multiple stable versions of the MI protocol
> > at a time, then have it print all of the versions like you suggested.
> > Also, above what you suggested, I think the front end should be able to
> > select the version it wants from the list. Is this OK?
> >
> > I'd like to work on this patch as soon as possible, so that I can start
> > using it. Is the multiple stable version approach with negotiation OK?
>
> I think it's pretty clear that no one else likes the idea of
> negotiating. I certainly don't.
>
> I believe that printing the latest stable version of MI is plenty
> adequate. If the front end wants a development version of MI it can
> use -i=mi; if it wants the latest stable version it can use that
> version; if it does not recognize that version it can use the latest
> version it recognizes. If you encounter a situation in which that
> version no longer works, have it removed from GDB.
OK, I want to make it clear that I think this solution is terrible.
However, hoping that the GDB community knows more than I, I'll agree.
Starting GDB with -i=mi<n> will not change the MI output. However,
starting GDB with -i=mi will have GDB print the latest stable version
even though it will start GDB in it's latest development version or the
latest stable version. For some odd reason in this mode, GDB will print
the latest stable version even though it may have absolutely nothing to
do with the version it will be communicating with.
So, I'll basically start GDB with -i=mi and get the latest stable
version. However, since I won't know what version I just started GDB in,
the version it just spat out, or a development version, I'll *have* to
restart GDB no matter what.
So, I'll read the first line ( which is the latest stable version ), and
then kill GDB and restart it in the mode that I support.
This solution,
* *requires* a restart
* requires printing the latest stable version even though GDB may not be
even speaking that version
* says *nothing* about other versions that GDB supports
* gives no way for a front end to determine if it is using a
deprecated protocol.
* puts the bug finding of the MI protocol on the users, even though the
protocols have been deprecated.
If this is the wish of the GDB community, then this is what I'll implement.
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-19 14:18 ` Daniel Jacobowitz
2004-10-19 19:28 ` Bob Rossi
@ 2004-10-19 20:17 ` Eli Zaretskii
1 sibling, 0 replies; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-19 20:17 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
> Date: Tue, 19 Oct 2004 09:28:24 -0400
> From: Daniel Jacobowitz <drow@false.org>
>
> I believe that printing the latest stable version of MI is plenty
> adequate.
I agree.
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 17:41 ` Dave Korn
2004-10-06 17:55 ` 'Bob Rossi'
@ 2004-10-06 18:43 ` Andrew Cagney
2004-10-06 18:54 ` 'Bob Rossi'
1 sibling, 1 reply; 212+ messages in thread
From: Andrew Cagney @ 2004-10-06 18:43 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Bob Rossi', 'Eli Zaretskii', gdb
>>> Will someone explain to me how they expect to write a parser
>>> capable of
>>> getting some information out of MI2, but prove to me that it will work
>>> with MI100.
>
>
> Simple.
>
> Any time anyone proposes changing the output format of the -mi-version
> command, or removing it, we'll just say no. Fr'ex:
>
> The -mi-version command will ALWAYS AND FOREVER output a string of the
> format
>
> "Highest supported MI version is XXXX"
anything like that.
> where XXXX is an ASCII decimal integer. Any program can then read the
> output from an invocation of gdb and simply discard everything up until it
> finds that string, then parse the integer out.
Right, and tested (as always) using the testsuite.
I find this focus on such pedantic details both puzzling and time
wasting. Especially given that any code intended to handle multiple MI
variants must be adhoc. Otherwize it won't work with all the variants
that pre-date the above - mi0, mi1, mi2 (prior to the above extension.
MI needs is additional commands and extensions, driven by the needs of
Free software projects. Neither of those - EMACS and Eclipse - appear
to be having problems this technical nits such as this.
Andrew
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 18:43 ` Andrew Cagney
@ 2004-10-06 18:54 ` 'Bob Rossi'
2004-10-06 19:19 ` Andrew Cagney
0 siblings, 1 reply; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-06 18:54 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Dave Korn, 'Eli Zaretskii', gdb
On Wed, Oct 06, 2004 at 02:41:09PM -0400, Andrew Cagney wrote:
>
> >>>Will someone explain to me how they expect to write a parser
> >>>capable of
> >>>getting some information out of MI2, but prove to me that it will work
> >>>with MI100.
> >
> >
> > Simple.
> >
> > Any time anyone proposes changing the output format of the -mi-version
> >command, or removing it, we'll just say no. Fr'ex:
> >
> > The -mi-version command will ALWAYS AND FOREVER output a string of the
> >format
> >
> >"Highest supported MI version is XXXX"
>
> anything like that.
>
> >where XXXX is an ASCII decimal integer. Any program can then read the
> >output from an invocation of gdb and simply discard everything up until it
> >finds that string, then parse the integer out.
>
> Right, and tested (as always) using the testsuite.
>
> I find this focus on such pedantic details both puzzling and time
> wasting. Especially given that any code intended to handle multiple MI
> variants must be adhoc. Otherwize it won't work with all the variants
> that pre-date the above - mi0, mi1, mi2 (prior to the above extension.
You are stating that a parser that implements an MIn Output syntax has
to be adhoc? I plan on having a parser for each of these interface's and
none of them is adhoc. I don't think you should force your adhoc
approach onto the front end developers.
> MI needs is additional commands and extensions, driven by the needs of
> Free software projects. Neither of those - EMACS and Eclipse - appear
> to be having problems this technical nits such as this.
I can't explain why.
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 18:54 ` 'Bob Rossi'
@ 2004-10-06 19:19 ` Andrew Cagney
2004-10-06 19:25 ` 'Bob Rossi'
0 siblings, 1 reply; 212+ messages in thread
From: Andrew Cagney @ 2004-10-06 19:19 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: Dave Korn, 'Eli Zaretskii', gdb
>>> I find this focus on such pedantic details both puzzling and time
>>> wasting. Especially given that any code intended to handle multiple MI
>>> variants must be adhoc. Otherwize it won't work with all the variants
>>> that pre-date the above - mi0, mi1, mi2 (prior to the above extension.
s/handle multiple/handle initial negotiation of multiple/
As everyone else has pointed out, with the negitiation done, the real
parser can be loaded.
> You are stating that a parser that implements an MIn Output syntax has
> to be adhoc? I plan on having a parser for each of these interface's and
> none of them is adhoc. I don't think you should force your adhoc
> approach onto the front end developers.
>
>
>>> MI needs is additional commands and extensions, driven by the needs of
>>> Free software projects. Neither of those - EMACS and Eclipse - appear
>>> to be having problems this technical nits such as this.
>
>
> I can't explain why.
Andrew
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 19:19 ` Andrew Cagney
@ 2004-10-06 19:25 ` 'Bob Rossi'
0 siblings, 0 replies; 212+ messages in thread
From: 'Bob Rossi' @ 2004-10-06 19:25 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Dave Korn, 'Eli Zaretskii', gdb
On Wed, Oct 06, 2004 at 03:16:20PM -0400, Andrew Cagney wrote:
>
> >>>I find this focus on such pedantic details both puzzling and time
> >>>wasting. Especially given that any code intended to handle multiple MI
> >>>variants must be adhoc. Otherwize it won't work with all the variants
> >>>that pre-date the above - mi0, mi1, mi2 (prior to the above extension.
>
> s/handle multiple/handle initial negotiation of multiple/
>
> As everyone else has pointed out, with the negitiation done, the real
> parser can be loaded.
Yes, this is obvious and it's not the problem.
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* RE: probing GDB for MI versions
2004-10-06 17:24 ` 'Bob Rossi'
2004-10-06 17:31 ` Daniel Jacobowitz
@ 2004-10-06 17:36 ` Dave Korn
2004-10-06 17:51 ` Paul Koning
2 siblings, 0 replies; 212+ messages in thread
From: Dave Korn @ 2004-10-06 17:36 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: 'Eli Zaretskii', gdb
> -----Original Message-----
> From: 'Bob Rossi'
> Sent: 06 October 2004 18:22
> I guess the bottom line is, I already have a parser that is capable of
> dealing with a specific version of MI's output. I don't want
> to start up
> MI with an adhoc parser, just to figure out what real parser I should
> use. This seems not correct to me, and I guess it's the issue to deal
> with.
It's absolutely correct. You have the tools for the job, but you need a
piece of information in order to select the correct tool. Since you cannot
use the tool to get the information to select the tool to .......... as you
so correctly point out, the answer is to use a _different_ tool. And a
crude ad-hoc parser is just the tool for the job.
> The problem is, we would be adding a command to the MI
> function set that
> would not be able to be parsed and understood with an MI parser. This
> seems really wrong to me. It's probably the issue we should be
> discussing.
There's no reason why your version-specific MI parsers shouldn't both be
able to understand the output from the -mi-version command as well. But you
will need the ad-hoc one to get started with. If you don't like the idea of
an ad-hoc parser, you could always call it a "recognizer" instead......
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 17:24 ` 'Bob Rossi'
2004-10-06 17:31 ` Daniel Jacobowitz
2004-10-06 17:36 ` Dave Korn
@ 2004-10-06 17:51 ` Paul Koning
2004-10-06 18:09 ` Bob Rossi
2 siblings, 1 reply; 212+ messages in thread
From: Paul Koning @ 2004-10-06 17:51 UTC (permalink / raw)
To: bob; +Cc: dk, eliz, gdb
>>>>> "Bob" == Bob Rossi <Bob> writes:
>> > Is this the general feel of the community?
>>
>> Well, it's not what I feel, as I hope I've explained patiently
>> above. I wouldn't care to speak for the community at large, but I
>> would be surprised if anyone else felt that it was wrong to
>> generate a parser from the MI output syntax. What I feel is wrong
>> is your assumption that a generated parser is the only possible
>> means of processing plain ascii human readable text for the
>> purpose of finding and extracting a single integer value.
Bob> I guess the bottom line is, I already have a parser that is
Bob> capable of dealing with a specific version of MI's output. I
Bob> don't want to start up MI with an adhoc parser, just to figure
Bob> out what real parser I should use. This seems not correct to me,
Bob> and I guess it's the issue to deal with.
Bob, that actually IS correct and the conventional way to handle
things. In typical protocol design, the conversation starts with a
message that carries version information. The protocol state machine
initially comes up in a state where it expects that message and knows
how to find the version information. Once it knows that, it flips to
the state machine for that version.
Note that the "ad hoc" part typically only involves one or two
messages and often only a small part of the content of those
messages. For example, the initial message might be a "create
connection" message, carrying dozens of fields one of which is a
version number. The first step is to find that version number; after
that is known, all the rest including the full parse of that initial
message can be done by the full parse machinery.
(Alternatively, there might be a combined state machine -- in your
notation, that would be a grammar for the union of MI1 and MI2, with
condition checking on the version number to forbid certain production
rules. That may work for some protocols; I doubt it's a sensible
answer for MI.)
paul
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 17:51 ` Paul Koning
@ 2004-10-06 18:09 ` Bob Rossi
0 siblings, 0 replies; 212+ messages in thread
From: Bob Rossi @ 2004-10-06 18:09 UTC (permalink / raw)
To: Paul Koning; +Cc: dk, eliz, gdb
On Wed, Oct 06, 2004 at 01:47:57PM -0400, Paul Koning wrote:
> >>>>> "Bob" == Bob Rossi <Bob> writes:
>
> >> > Is this the general feel of the community?
> >>
> >> Well, it's not what I feel, as I hope I've explained patiently
> >> above. I wouldn't care to speak for the community at large, but I
> >> would be surprised if anyone else felt that it was wrong to
> >> generate a parser from the MI output syntax. What I feel is wrong
> >> is your assumption that a generated parser is the only possible
> >> means of processing plain ascii human readable text for the
> >> purpose of finding and extracting a single integer value.
>
> Bob> I guess the bottom line is, I already have a parser that is
> Bob> capable of dealing with a specific version of MI's output. I
> Bob> don't want to start up MI with an adhoc parser, just to figure
> Bob> out what real parser I should use. This seems not correct to me,
> Bob> and I guess it's the issue to deal with.
>
> Bob, that actually IS correct and the conventional way to handle
> things. In typical protocol design, the conversation starts with a
> message that carries version information. The protocol state machine
> initially comes up in a state where it expects that message and knows
> how to find the version information. Once it knows that, it flips to
> the state machine for that version.
>
> Note that the "ad hoc" part typically only involves one or two
> messages and often only a small part of the content of those
> messages. For example, the initial message might be a "create
> connection" message, carrying dozens of fields one of which is a
> version number. The first step is to find that version number; after
> that is known, all the rest including the full parse of that initial
> message can be done by the full parse machinery.
Yes, you are correct. I understand this. I think the problem is 2 fold.
It is confusing and (IMO) incorrect to add a command to the MI function
set that can not be used for the purposes that it needs to be by a program
that speaks the MI protocol. I new parser needs to be written that does
not conform to the MI protocol.
MI is an evolving protocol, and it would be useful to just have either a
command line swith, which could send info in a trivial line based
manner, or have a new interpreter, that only says what other
interpreters that the current GDB supports.
These are simple solutions that would not involve much from the front
end developer and would result in code that could be written probably to
a format that will not change.
Thanks,
Bob Rosi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 16:31 ` 'Bob Rossi'
2004-10-06 16:46 ` Nathan J. Williams
2004-10-06 16:57 ` Dave Korn
@ 2004-10-06 17:05 ` Alain Magloire
2 siblings, 0 replies; 212+ messages in thread
From: Alain Magloire @ 2004-10-06 17:05 UTC (permalink / raw)
To: 'Bob Rossi'; +Cc: Dave Korn, 'Eli Zaretskii', gdb
>
> On Wed, Oct 06, 2004 at 12:50:34PM +0100, Dave Korn wrote:
> > > -----Original Message-----
> > > From: gdb-owner On Behalf Of Bob Rossi
> > > Sent: 06 October 2004 12:39
> >
> > > Unfortunately this topic is on two different threads. I feel
> > > badly that I
> > > am wasting your time here with bad descriptions of the
> > > "catch-22". This
> > > is to help make my opinion clear on why it is a "catch-22" and not
> > > possible.
> > >
> > > The front end has parsers for different versions of GDB's
> > > MI protocol.
> > > The parser for MI2 may not work for the MI3 protocol.
> > > The parser for the MI3 protocol may not work for the MI2 protocol.
> > > The front end *can not* start up GDB just by using -interpreter=mi
> > > because it doesn't know what parser to use in this situation.
> > > Can we agree on this point for starters?
> >
> > No, we can't. As long as the output from the -mi-version MI command stays
> > in the same format, you can always parse that and determine which version to
> > use.
>
> Dave, you do not understand the problem at all. I do not appreciate your
> defininative answer, especially since it is incorrect.
>
> The actual MI output syntax is capable of changing between MI versions.
> If the MI4 output syntax (grammar) has an incompatible change with MI3,
> then
> * the MI3 parser will not even be capable of parsing and building a
> parse tree for the MI4 protocol.
> * the MI4 parser will not even be capable of parsing and building a
> parse tree for the MI3 protocol.
>
> It is not possible to understand the output of the command no matter how
> simple it is. If there is no parse tree, then there is no way to
> understand the output from GDB.
>
> > Everything else can change. You can start up with an utterly minimal,
> > unintelligent parser, that knows nothing except how to send a -mi-version
> > command and parse the output; that parser can then direct one of your
> > version-dependent parsers to take over.
>
> I don't understand the concept of an "utterly minimal unintelligent parser".
> That is rediculous. I am generating a parser from the grammar.
>
> There absolutly needs to be a way for the front end to ask GDB what
> versions of the MI protocol it supports.
>
> There is no way the front end can ask GDB what protocols it supports if
> it needs to talk to it with an MI protocol. Understood?
>
I'm not sure on your rationnale to reject Dave's proposition. It seems
to me it is a perfectly valid alternative for a front-end to probe
gdb and do an educated guess on what the better version of MI it
can support.
gdb --interpreter=mi executable
(gdb) 1-mi-level
1^done,value="1"
The front-end loads MI Parser level 1 and continue exchange with gdb.
The other approach that was suggested, seems also interresting;
asking gdb on the command line for the list of protocols.
This first pass probing will allow the front-end to make a good choice
also.
The first idea to keep on probing gdb :
$ gdb -i mi5 executable
Interpreter `mi45' unrecognized
# try a nother
$ gdb -i mi4 executable
Interpreter `mi4' unrecognized
$ gdb -i mi2 executable
Bingo !!!
seems cumbersone but should work.
The problem that I did not see you mention in any previous thread, is
when there is a bug fix !! for example:
-thread-list-ids, keep on crashing, the next version of gdb fixes
the problem, how will a front-end knows to not use "info threads" but
can now use "-thread-list-ids". Andrew's answer to this was to look
at the gdb version and make an educated guess, but we know the problem
with this, many distrubution have mangle gdb --version
(Just came back from a 2 weeks break, so I may have missed some context).
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-03 17:15 probing GDB for MI versions Bob Rossi
2004-10-04 9:00 ` Eli Zaretskii
@ 2004-10-06 19:16 ` Andrew Cagney
2004-10-06 19:20 ` Bob Rossi
1 sibling, 1 reply; 212+ messages in thread
From: Andrew Cagney @ 2004-10-06 19:16 UTC (permalink / raw)
To: Bob Rossi; +Cc: GDB
If a current GDB were modified to list mi "versions" then it would only
print mi2, which is the version selected by -i=mi. If your front end
specifies -i=mi1 then you're on your own - it's not tested - it doesn't
work.
Andrew
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 19:16 ` Andrew Cagney
@ 2004-10-06 19:20 ` Bob Rossi
2004-10-06 20:10 ` Alain Magloire
2004-10-06 20:13 ` Andrew Cagney
0 siblings, 2 replies; 212+ messages in thread
From: Bob Rossi @ 2004-10-06 19:20 UTC (permalink / raw)
To: Andrew Cagney; +Cc: GDB
On Wed, Oct 06, 2004 at 03:09:58PM -0400, Andrew Cagney wrote:
> If a current GDB were modified to list mi "versions" then it would only
> print mi2, which is the version selected by -i=mi. If your front end
> specifies -i=mi1 then you're on your own - it's not tested - it doesn't
> work.
WHAT?!? This is what I have been asking all along? It was the foundation
to this conversation. Where were you to inform everyone of this?
Are you saying that old versions of MI are not supported by GDB? Only
the last official release of the MI protocol is supported and that no
other versions that it used to speak with are supported or tested?
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 19:20 ` Bob Rossi
@ 2004-10-06 20:10 ` Alain Magloire
2004-10-06 20:15 ` Bob Rossi
2004-10-06 20:13 ` Andrew Cagney
1 sibling, 1 reply; 212+ messages in thread
From: Alain Magloire @ 2004-10-06 20:10 UTC (permalink / raw)
To: gdb
>
> On Wed, Oct 06, 2004 at 03:09:58PM -0400, Andrew Cagney wrote:
> > If a current GDB were modified to list mi "versions" then it would only
> > print mi2, which is the version selected by -i=mi. If your front end
> > specifies -i=mi1 then you're on your own - it's not tested - it doesn't
> > work.
>
> WHAT?!? This is what I have been asking all along? It was the foundation
> to this conversation. Where were you to inform everyone of this?
>
But I think that was the folks been saying. If you choose a specific
version to start gdb in your front-end say, "-i=mi1" why do you care
later to know about "mi2" or "mix" ?
If you start with "-i=mi", it will be handy to know which mi level,
in this case the front-end can take appropriate action
or restart trying a known version "-i=mi1"
Am I missing something here ?
I'm curious to understand why you reject the others propositions as inadequate.
> Are you saying that old versions of MI are not supported by GDB? Only
> the last official release of the MI protocol is supported and that no
> other versions that it used to speak with are supported or tested?
>
how did you manage to come up with such conclusions ?
--
alain
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 20:10 ` Alain Magloire
@ 2004-10-06 20:15 ` Bob Rossi
0 siblings, 0 replies; 212+ messages in thread
From: Bob Rossi @ 2004-10-06 20:15 UTC (permalink / raw)
To: Alain Magloire; +Cc: gdb
On Wed, Oct 06, 2004 at 03:53:41PM -0400, Alain Magloire wrote:
> >
> > On Wed, Oct 06, 2004 at 03:09:58PM -0400, Andrew Cagney wrote:
> > > If a current GDB were modified to list mi "versions" then it would only
> > > print mi2, which is the version selected by -i=mi. If your front end
> > > specifies -i=mi1 then you're on your own - it's not tested - it doesn't
> > > work.
> >
> > WHAT?!? This is what I have been asking all along? It was the foundation
> > to this conversation. Where were you to inform everyone of this?
> >
>
> But I think that was the folks been saying. If you choose a specific
> version to start gdb in your front-end say, "-i=mi1" why do you care
> later to know about "mi2" or "mix" ?
>
> If you start with "-i=mi", it will be handy to know which mi level,
> in this case the front-end can take appropriate action
> or restart trying a known version "-i=mi1"
>
> Am I missing something here ?
> I'm curious to understand why you reject the others propositions as inadequate.
Alain, I started some talks several days ago about how GDB behaves when
it comes to backwards compatibility of the MI protocols. Everyone has
told me that it supports the current official release, and it supports
all of the old releases.
As far as I can tell, several days later, andrew comes on the seen and
says that GDB only plans on supporting the last official release. This
is information I would to have like to had several days ago. Better yet,
it's information that should be documented for all to easily find the
answer to.
> > Are you saying that old versions of MI are not supported by GDB? Only
> > the last official release of the MI protocol is supported and that no
> > other versions that it used to speak with are supported or tested?
> >
>
> how did you manage to come up with such conclusions ?
I am assuming this front what Andrew said below,
> > > If a current GDB were modified to list mi "versions" then it would only
> > > print mi2, which is the version selected by -i=mi. If your front end
> > > specifies -i=mi1 then you're on your own - it's not tested - it doesn't
> > > work.
Bobby
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 19:20 ` Bob Rossi
2004-10-06 20:10 ` Alain Magloire
@ 2004-10-06 20:13 ` Andrew Cagney
2004-10-08 10:28 ` Eli Zaretskii
1 sibling, 1 reply; 212+ messages in thread
From: Andrew Cagney @ 2004-10-06 20:13 UTC (permalink / raw)
To: Bob Rossi; +Cc: GDB
> On Wed, Oct 06, 2004 at 03:09:58PM -0400, Andrew Cagney wrote:
>
>>> If a current GDB were modified to list mi "versions" then it would only
>>> print mi2, which is the version selected by -i=mi. If your front end
>>> specifies -i=mi1 then you're on your own - it's not tested - it doesn't
>>> work.
>
>
> WHAT?!? This is what I have been asking all along? It was the foundation
> to this conversation. Where were you to inform everyone of this?
s/everyone/you/. I've been reading the thread.
> Are you saying that old versions of MI are not supported by GDB? Only
> the last official release of the MI protocol is supported and that no
> other versions that it used to speak with are supported or tested?
I'm simply pointing out the obvious - what we don't test [likely]
doesn't work. I certainly wouldn't be putting the sheep station(1) on
this one, given such odds.
Andrew
(1) Farm
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-06 20:13 ` Andrew Cagney
@ 2004-10-08 10:28 ` Eli Zaretskii
2004-10-08 18:48 ` Daniel Jacobowitz
0 siblings, 1 reply; 212+ messages in thread
From: Eli Zaretskii @ 2004-10-08 10:28 UTC (permalink / raw)
To: Andrew Cagney; +Cc: bob, gdb
> Date: Wed, 06 Oct 2004 16:09:42 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: GDB <gdb@sources.redhat.com>
>
> I'm simply pointing out the obvious - what we don't test [likely]
> doesn't work.
Well, that's true, but there _are_ tests for mi1 in testsuite/gdb.mi.
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: probing GDB for MI versions
2004-10-08 10:28 ` Eli Zaretskii
@ 2004-10-08 18:48 ` Daniel Jacobowitz
0 siblings, 0 replies; 212+ messages in thread
From: Daniel Jacobowitz @ 2004-10-08 18:48 UTC (permalink / raw)
To: gdb
On Fri, Oct 08, 2004 at 11:06:36AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 06 Oct 2004 16:09:42 -0400
> > From: Andrew Cagney <cagney@gnu.org>
> > Cc: GDB <gdb@sources.redhat.com>
> >
> > I'm simply pointing out the obvious - what we don't test [likely]
> > doesn't work.
>
> Well, that's true, but there _are_ tests for mi1 in testsuite/gdb.mi.
Removed on 2004-02-13...
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 212+ messages in thread
[parent not found: <5956F1E2-EB0D-11D8-9949-000A9569836A@apple.com>]
* Re: GDB/XMI (XML Machine Interface)
[not found] <5956F1E2-EB0D-11D8-9949-000A9569836A@apple.com>
@ 2004-08-11 0:51 ` Chris Friesen
[not found] ` <gdb001@speakeasy.net>
0 siblings, 1 reply; 212+ messages in thread
From: Chris Friesen @ 2004-08-11 0:51 UTC (permalink / raw)
To: gdb
Hi Bob,
I'm not defending MI, I just haven't had any problems parsing MI
output, mi0 or mi1, using Apple's branch of gdb. The structure is well
defined and if you parse the payload into arrays and dictionaries then
it's not so bad to deal with.
The versioning problem you mention is solved by having a specification
for backward compatibility and not by any inherent virtue of XML. (We
could just add a version field to MI output...FYI: Apple's branch has
an MI verify command to test for support of MI commands.) So I'm not
sure what XML delivers for MI other than people can use a 'standard'
parser. I guess the DTD's are a nice place for the spec of the MI
commands and there are tools to help validate against them, so that's a
win. (The code is *not* the spec people...)
> From: Bob Rossi <bob@brasko.net>
> Date: August 10, 2004 1:14:40 PM PDT
> To: gdb@sources.redhat.com
> Subject: GDB/XMI (XML Machine Interface)
>
> Hi,
>
> As most of you know, I have been writing a front end to GDB called
> CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
>
> 1.2 The Objective
>
> The objective of GDB/XMI is to create a reliable protocol between
> GDB and the front end controlling GDB.
Is MI not reliable? Reliable is good.
>
> 2. The GDB/XMI Overview
>
> 2.1 Passing Information between GDB and the front end
>
> All information passed between GDB and the front end is done in
> the form of an XML document. Each XMI command, generates an XML
> document, and is sent from GDB to the front end.
>
This would not be good for MI commands *to* gdb as developers of MI
commands often enter them by hand.
>
> 2.5 Version Management
>
> This model keeps front ends working with both old and new GDB's,
> which
> is unfortunately a task that most front ends have to and should deal
> with.
>
I don't see a new IDE supporting an old GDB, it might with minimum
version numbers for the MI commands, but the new IDE isn't going to
support a deprecated command if they choose to use the new MI command.
The IDE is going to choose features over using an old version of GDB.
Backward compatibility of MI commands will make it so my old IDE can
use a new GDB, which is more important.
> 3.3.2 GDB/MI Output
>
> (gdb)
> -stack-list-frames
>
> ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file=
> "test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file
> ="test.c",line="54"}]
>
> ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
> file="test.c",line="13"},frame={level="1",addr="0x080484f5",
> func="main",file="test.c",line="54"}]
>
> 3.3.3 The GDB/XMI Output
>
> <?xml version="1.0"?>
> <stack>
> <frame>
> <level>0</level>
> <addr>0x080483ef</addr>
> <func>short_func</func>
> <file>test.c</file>
> <line>13</line>
> </frame>
> <frame>
> <level>1</level>
> <addr>0x080484f5</addr>
> <func>main</func>
> <file>test.c</file>
> <line>54</line>
> </frame>
> </stack>
>
<snip>
Hate to say this but the MI output is more human readable for 'key' and
'value' (good for debugging) while the the XML is not friendly to my
scanning... the MI reads more like code. If you look at it, the MI has
the same tree structure as the XML, just written in a less pedantic
form. An MI to XML formatter/converter wouldn't be that hard.
Overall MI suffers most from not having a specification for the various
commands, as well as not documenting which platforms the commands are
supported on. I don't see a big benefit from using XML. It could be
tested by writing a simple MI to XML converter without having to make a
lot of changes to gdb.
Cheers,
-ChrisF
^ permalink raw reply [flat|nested] 212+ messages in thread
* GDB/XMI (XML Machine Interface)
@ 2004-08-10 20:14 Bob Rossi
2004-08-10 22:38 ` Kip Macy
` (5 more replies)
0 siblings, 6 replies; 212+ messages in thread
From: Bob Rossi @ 2004-08-10 20:14 UTC (permalink / raw)
To: gdb
Hi,
As most of you know, I have been writing a front end to GDB called CGDB.
However, for a while now, I have been a little disappointed with the MI
interface. In my RFC I have described the problems I have with MI and I
have proposed a new method of communication between GDB and the front
end.
If there is good feedback on this RFC, I will continue research on it,
filling in details that I thought would be best to wait until after an
initial acceptance.
If the RFC is accepted by the community I plan on implementing an
initial version of the XMI interface in GDB, and programming CGDB to
sit on top of GDB. This will at least give the community one open
source front end to GDB and an example to prove that the new
machine interface works.
I can't wait to hear your opinions/comments.
Thanks,
Bob Rossi
GDB/XMI (XML Machine Interface)
Robert Rossi
August 2004
bob@brasko.net
TABLE OF CONTENTS
1. Introduction
1.1 The Problem
1.2 The Objective
2. The GDB/XMI Overview
2.1 Passing Information between GDB and the front end
2.2 Parsing XMI Commands from GDB's output
2.3 Parsing the Inferior's output
2.4 Validation
2.5 Version Management
2.6 Understanding the XML data
3. GDB/XMI Specification
3.1 XMI Types
3.1.1 Scalar Types
3.1.2 Compound Types (Structs)
3.2 A Breakpoint Listing
3.2.1 The GDB/MI -break-list Specification
3.2.2 GDB/MI Output
3.2.3 The GDB/XMI Output
3.3 A Backtrace
3.3.1 The GDB/MI -stack-list-frames Specification
3.3.2 GDB/MI Output
3.3.3 The GDB/XMI Output
4. A GDB/XMI Example
4.1 The Inferior's Code
4.2 GDB/MI Output
4.3 GDB/XMI Output
4.4 A Brief Description of the XMI output
4.4.1 GDB_DISPLAY_PROMPT Document
4.4.2 GDB_WAITING_FOR_COMMAND Document
4.4.3 The Front End Transmits a Command
4.4.4 GDB_INFERIOR_STARTED Document
4.4.5 GDB_INFERIOR_FINISHED Document
5. Issues to resolve after RFC Initial approval.
5.1 If GDB will link to libxml, or just output XML
5.2 How the schema will represent each document sent to the front end
5.3 Separating GDB output and the Inferior output
5.4 If GDB recieves commands in XML
Preface
GDB/XMI is meant to be the successor of GDB/MI. It improves upon the
idea of GDB/MI and fixes many of the known issues that GDB/MI contains.
1. Introduction
1.1 The Problem
Writing a front end for GDB/MI means that a front end has to be able to
implement an ad hoc parser, capable of understanding all of the data
sent from GDB to it. For each version of GDB, functionality might change,
without ever allowing the GUI to understand what the interface differences
are in a scientific manner. Any guessing from version to version is a
best-chance scenario, leaving the front end guessing what functionality
a CVS snapshot has that has been installed on any particular distribution.
1.2 The Objective
The objective of GDB/XMI is to create a reliable protocol between
GDB and the front end controlling GDB. A goal of this project is to
remove most of the parsing from the front end, and move it to a
reliable parsing library, capable of validating the data it is
parsing, and building a tree representation of the data without
any front end infrastructure. It is believed that the protocol between
GDB and any front end can be automated in every front end and that it
is not necessary to have any front end developer worry about the syntax
or grammar of the actual commands sent between GDB and the front end.
Another goal of this project is to formalize the maintenance and
version management of the XMI commands, as GDB matures, and modifies the
XMI commands over time. The front end should be independent of the
XMI command versions, and should be able to determine what data is
available to it, without worrying about the version of any particular
XMI command.
It is believed this can help front end writers in several ways. First,
there will be a significant reduction of time spent in parsing the
obscure MI commands, and understanding what the output represents.
This gives front end developers a greater chance of actually getting
to 1.0 on any given front end, and allowing for much more time to
be spent on the look & feel of the front end, not including the much
needed features that most front ends do not have. Secondly, It will
reduce the code size of each front end, potentially reducing the number
of bugs, and allowing for a more reliable set of front ends that sit
on top of GDB.
2. The GDB/XMI Overview
GDB/XMI is based mostly on the model of GDB/MI. The major differences
are the need to pass the information from GDB to the front end via XML
documents and the ability to give the front end a schema, capable
of validating an XMI command.
2.1 Passing Information between GDB and the front end
All information passed between GDB and the front end is done in
the form of an XML document. Each XMI command, generates an XML
document, and is sent from GDB to the front end.
2.2 Parsing XMI Commands from GDB's output
XMI is the protocol between GDB and the front end. It is an XML
based Markup Language that is intended to be the Machine Interface
between GDB and any application that would like to communicate with it.
An XML document is started and stopped with escape sequences. These
sequences tell the front end when an XML document is being sent, and
when the XML document is done being sent. For each XMI command, GDB
will output an escape sequence saying that it is ready to transmit
the XML Document response. Then it will output the XML Document. Finally,
GDB will transmit another escape sequence, saying that the document
has been completed. This allows the front end to understand what
information to pass to the XML parser, and what information is output
from the inferior.
2.3 Parsing the Inferior's output
When the GDB sends the XML command stating that the inferior has started,
the front end can then parse the output of GDB waiting for an escape
sequence, saying that the inferior has stopped running. All of the
data captured between these two points are output from the inferior.
It can be processed real time and sent to the user to update them of what
the inferior is doing. Any asynchronous commands can of course break the
stream and output data to the front end, and then notify the front end
that the inferior has started again. This easily allows the front end
to understand what data is from GDB and what data is from the inferior.
The only downside to this design is that escape sequences are needed.
However, the only way to change that is to allow the inferior's output
to be on a separate communication link (pipe) than the output of GDB.
So far, this has not happened. Section 5, point 3 illustrates that it
would be desirable to split GDB's and the inferior's output up, this
would cause the protocol between GDB and the front end to not include
the escape sequences before and after each XMI document sent.
2.4 Validation
The validation document (DTD) has to be up to date with the XMI
command for the particular version of GDB. Also, this document has to
be in one place. Therefore, I propose, that an XMI command be given to
output to the front end all of the XMI validation documents (DTD?) or
pass a parameter to have GDB output the validation document for a
particular XMI command. This document will prove that the XMI commands
are valid, and GDB is not misbehaving. Front end writers can report
bad output from GDB easily, and the development process can self-adjust.
The main goal of this tactic is that GDB is capable of telling front ends
if the output it is generating is correct. Front ends can use this
capability, at virtually no extra cost, to determine if the protocol
between the two processes is incorrect. By allowing GDB to keep the
Schema's, the DRY principle is honored, and things will not get out of
date.
2.5 Version Management
From version to version, XMI commands will be modified. Commands will
be fully backwards compatible, from version to version, allowing only
fields to be added, or providing more information than is already
there. The front ends will not have to be updated in this way,
allowing existing front ends to always be able to use at least the
amount of information that they have been programmed to understand.
Since it is not a perfect world, it is not always possible to make
XMI commands backwards compatible. In this case, the XMI command to
be replaced will be marked as deprecated and a new XMI command will
be generated to take it's place. This new command will force the
front end writer to program the functionality of the new command into
there program, and from then on, will again have a front end capable
of parsing the new command with a new GDB, and the old command with
the old GDB.
This model keeps front ends working with both old and new GDB's, which
is unfortunately a task that most front ends have to and should deal with.
2.6 Understanding the XML data
Since all commands are backwards compatible, the tree representation
for any XMI command can be walked the same way, no matter what version
of the XMI command is being used. The front end is capable of throwing
away any data that it does not know how or wish to process, allowing
it to pick and choose what data is appropriate.
3. GDB/XMI Specification
3.1 XMI Types
The XMI types are to be used for validation purposes. They can also
be used to tell the front end what kind of type a particular element
is that GDB is sending to the front end.
3.1.1 Scalar Types
<int8> one-byte singed integer
<uint8> one-byte unsigned integer
<int16> two-byte signed integer
<uint16> two-byte unsigned integer
<int32> four-byte signed integer
<uint32> four-byte unsigned integer
<int64> eight-byte signed integer
<uint64> eight-byte unsigned integer
<boolean> 0 (false) or 1 (true)
<string> string
<float> single-precision signed floating point number
<double> double-precision signed floating point number
3.1.2 Compound Types (Structs)
A "struct" is a compound value in which accessor name is the only
distinction among member values, and no accessor has the same name
as any other.
<struct_example>
<element_one>one</element_one>
<element_two>two</element_two>
<element_three>three</element_three>
</struct_example>
A Schema for such a struct could look like this.
<element name="struct_example">
<complexType>
<element name="element_one" type="string"/>
<element name="element_two" type="string"/>
<element name="element_three" type="string"/>
</complexType>
</struct_example>
3.2 A Breakpoint Listing
3.2.1 The GDB/MI -break-list Specification
The -break-list Command
Displays the list of inserted breakpoints, showing the following fields:
`Number'
number of the breakpoint
`Type'
type of the breakpoint: `breakpoint' or `watchpoint'
`Disposition'
should the breakpoint be deleted or disabled when it is hit:
`keep' or `nokeep' `Enabled' is the breakpoint enabled or no:
`y' or `n'
`Address'
memory location at which the breakpoint is set
`What'
logical location of the breakpoint, expressed by function name,
file name, line number
`Times'
number of times the breakpoint has been hit
If there are no breakpoints or watchpoints, the BreakpointTable body
field is an empty list.
3.2.2 GDB/MI Output
-break-list
^done,
BreakpointTable={
nr_rows="4",nr_cols="6",
hdr=[
{width="3",alignment="-1",col_name="number",colhdr="Num"},
{width="14",alignment="-1",col_name="type",colhdr="Type"},
{width="4",alignment="-1",col_name="disp",colhdr="Disp"},
{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
{width="10",alignment="-1",col_name="addr",colhdr="Address"},
{width="40",alignment="2",col_name="what",colhdr="What"}
],
body=[
bkpt={
number="1",type="breakpoint",disp="keep",enabled="y",
addr="0x0804844f",func="main",file="test.c",line="35",times="1"},
bkpt={
number="2",type="breakpoint",disp="keep",enabled="y",
addr="0x080483ef",func="short_func",file="test.c",line="13",times="0"},
bkpt={
number="3",type="breakpoint",disp="keep",enabled="y",
addr="0x0804851d",func="main",file="test.c",line="61",times="0"},
bkpt={
number="4",type="hw watchpoint",disp="keep",enabled="y",addr="",
what="argc",times="0"}
]
}
3.2.3 The GDB/XMI Output
<?xml version="1.0"?>
<breakpoints>
<breakpoint>
<number>1</number>
<type>breakpoint</type>
<disp>keep</disp>
<enabled>1</enabled>
<addr>0x0804844f</addr>
<func>main</func>
<file>test.c</file>
<line>35</line>
<times>0</times>
</breakpoint>
<breakpoint>
<number>2</number>
<type>breakpoint</type>
<disp>keep</disp>
<enabled>1</enabled>
<addr>0x080483ef</addr>
<func>short_func</func>
<file>test.c</file>
<line>13</line>
<times>0</times>
</breakpoint>
<breakpoint>
<number>3</number>
<type>breakpoint</type>
<disp>keep</disp>
<enabled>1</enabled>
<addr>0x0804851d</addr>
<func>main</func>
<file>test.c</file>
<line>61</line>
<times>0</times>
</breakpoint>
<watchpoint>
<number>4</number>
<type>watchpoint</type>
<disp>keep</disp>
<enabled>1</enabled>
<addr></addr>
<what>argc</what>
<times>0</times>
</watchpoint>
</breakpoints>
3.3 A Backtrace
3.3.1 The GDB/MI -stack-list-frames Specification
The -stack-list-frames Command
Synopsis: -stack-list-frames [ low-frame high-frame ]
List the frames currently on the stack. For each frame it displays
the following info:
`level'
The frame number, 0 being the topmost frame,
i.e. the innermost function.
`addr'
The $pc value for that frame.
`func'
Function name.
`file'
File name of the source file where the function lives.
`line'
Line number corresponding to the $pc.
If invoked without arguments, this command prints a backtrace for
the whole stack. If given two integer arguments, it shows the frames
whose levels are between the two arguments (inclusive). If the two
arguments are equal, it shows the single frame at the corresponding level.
3.3.2 GDB/MI Output
(gdb)
-stack-list-frames
^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file="test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file="test.c",line="54"}]
^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
file="test.c",line="13"},frame={level="1",addr="0x080484f5",
func="main",file="test.c",line="54"}]
3.3.3 The GDB/XMI Output
<?xml version="1.0"?>
<stack>
<frame>
<level>0</level>
<addr>0x080483ef</addr>
<func>short_func</func>
<file>test.c</file>
<line>13</line>
</frame>
<frame>
<level>1</level>
<addr>0x080484f5</addr>
<func>main</func>
<file>test.c</file>
<line>54</line>
</frame>
</stack>
4. A GDB/XMI Example
4.1 The Inferior's Code
#include <stdio.h>
int main(int argc, char **argv){
printf ( "newline\n" e;
printf ( "nonewline" );
return 0;
}
4.2 GDB/MI Output
(gdb)
-exec-run
^running
(gdb)
newline
nonewline*stopped,reason="exited-normally"
(gdb)
4.3 GDB/XMI Output
Assuming that the escape sequence is simply \027
The whitespace is not necessary, and is simply there for presentation.
\027<GDB_DISPLAY_PROMPT>
(gdb)
</GDB_DISPLAY_PROMPT>\027
\027<GDB_WAITING_FOR_COMMAND/>\027
-exec-run
\027<GDB_INFERIOR_STARTED/>\027
newline
nonewline\027<GDB_INFERIOR_FINISHED/>\027
\027<GDB_DISPLAY_PROMPT>
gdb
</GDB_DISPLAY_PROMPT>\027
\027<GDB_WAITING_FOR_COMMAND/>\027
4.4 A Brief Description of the XMI output
4.4.1 GDB_DISPLAY_PROMPT Document
The front end receives the document below.
\027<GDB_DISPLAY_PROMPT>
(gdb)
</GDB_DISPLAY_PROMPT>\027
The front end sends the data to the XML processor, which then tells
it that the current prompt is "(gdb) ". The front end can choose to
do whatever it wants with this information, including display it to the
user, or just ignore it.
4.4.2 GDB_WAITING_FOR_COMMAND Document
Next, GDB transmits the document below.
\027<GDB_WAITING_FOR_COMMAND/>\027
The front end receives the data and sends it to the XML processor. The
processor parses the document and the front end can determine that
the command says that GDB is ready to accept a user command. At this
point, the front end understands that it is OK to transmit a command to
GDB.
4.4.3 The Front End Transmits a Command
The front end transmits the command "-exec-run".
Should the front end transmit commands in XML or just
ordinary text?
4.4.4 GDB_INFERIOR_STARTED Document
GDB would send a document telling the front end that the inferior
has begun processing.
\027<GDB_INFERIOR_STARTED/>\027
Everything the front end processes from the pipe from this point
until the next GDB XMI Document transmission is from the inferior.
It is considered to be output that the inferior would like to have
the user see. The front end can process this data realtime, since
it does not have to be sent to the XML parser for processing.
The data
newline
nonewline
is outputted by the inferior, and the front end processes this data
realtime, understanding that it is not the output of GDB.
4.4.5 GDB_INFERIOR_FINISHED Document
GDB would send a document telling the front end that the inferior
has finished processing.
\027<GDB_INFERIOR_FINISHED/>\027
This alerts the front end that GDB is now outputting XMI commands
again. The front end no longer expects information from the inferior.
Optionally, GDB could output a XMI command stating that a signal
has been caught, or some other asynchronous event has occurred. This
could be something like
\027<GDB_SIGNAL_CAUGHT>
<SIGNAL>
<NAME>SIGINT</NAME>
<NUMBER>2</NUMBER>
<COMMENT>Interrupt from keyboard</COMMENT>
</SIGNAL>
</GDB_SIGNAL_CAUGHT>\027
In this way, GDB could alert the front end of any asynchronous event,
and no special parsing mechanism will have to take place to
understand such actions.
5. Issues to resolve after RFC Initial approval.
5.1 If GDB will link to libxml, or just output XML
It would be nice if GDB was capable of sending the XML documents by
creating them via libxml. However, libxml2 is licensed under the
MIT license. Also, I don't know if libxml2 is as portable as GDB.
5.2 How the schema will represent each document sent to the front end
If there will be one schema for each XMI document, or a schema
that represents every XMI document.
5.3 Separating GDB output and the Inferior output
If GDB can output it's data on a different pipe than the
inferior then the escape sequences would not be needed to tell
the front end which data is from GDB and which is from the inferior.
This would simply the front end processing.
5.4 If GDB recieves commands in XML
If GDB links in libxml2, then it could easy receive commands from the
front end in XML. This would be a nice feature, although, since the
parser in GDB is only written once, it doesn't really matter what format
the commands are that is sent to it.
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: GDB/XMI (XML Machine Interface)
2004-08-10 20:14 GDB/XMI (XML Machine Interface) Bob Rossi
@ 2004-08-10 22:38 ` Kip Macy
2004-08-11 0:17 ` Michael Chastain
` (4 subsequent siblings)
5 siblings, 0 replies; 212+ messages in thread
From: Kip Macy @ 2004-08-10 22:38 UTC (permalink / raw)
To: Bob Rossi; +Cc: gdb, nomura, pg
Excellent. I've been thinking about the same thing for quite some time,
but have hesitated to propose it because of the animosity towards XML
that I see in many places in the OSS community. It seems that many
prefer to create a new format for every application.
The actual MI output is not anywhere nearly as clean as the grammar that
is documented. My parser (which I would not have had to spend days
writing and debugging if MI were XML) has a larger number of actions
than is documented. And yet there are still many cases that it cannot
handle.
I would eagerly support this effort.
-Kip
On Tue, 10 Aug 2004, Bob Rossi wrote:
> Hi,
>
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
>
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
>
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to
> sit on top of GDB. This will at least give the community one open
> source front end to GDB and an example to prove that the new
> machine interface works.
>
> I can't wait to hear your opinions/comments.
>
> Thanks,
> Bob Rossi
>
> GDB/XMI (XML Machine Interface)
>
> Robert Rossi
> August 2004
> bob@brasko.net
>
>
> TABLE OF CONTENTS
>
> 1. Introduction
> 1.1 The Problem
> 1.2 The Objective
>
> 2. The GDB/XMI Overview
> 2.1 Passing Information between GDB and the front end
> 2.2 Parsing XMI Commands from GDB's output
> 2.3 Parsing the Inferior's output
> 2.4 Validation
> 2.5 Version Management
> 2.6 Understanding the XML data
>
> 3. GDB/XMI Specification
> 3.1 XMI Types
> 3.1.1 Scalar Types
> 3.1.2 Compound Types (Structs)
> 3.2 A Breakpoint Listing
> 3.2.1 The GDB/MI -break-list Specification
> 3.2.2 GDB/MI Output
> 3.2.3 The GDB/XMI Output
> 3.3 A Backtrace
> 3.3.1 The GDB/MI -stack-list-frames Specification
> 3.3.2 GDB/MI Output
> 3.3.3 The GDB/XMI Output
>
> 4. A GDB/XMI Example
> 4.1 The Inferior's Code
> 4.2 GDB/MI Output
> 4.3 GDB/XMI Output
> 4.4 A Brief Description of the XMI output
> 4.4.1 GDB_DISPLAY_PROMPT Document
> 4.4.2 GDB_WAITING_FOR_COMMAND Document
> 4.4.3 The Front End Transmits a Command
> 4.4.4 GDB_INFERIOR_STARTED Document
> 4.4.5 GDB_INFERIOR_FINISHED Document
>
> 5. Issues to resolve after RFC Initial approval.
> 5.1 If GDB will link to libxml, or just output XML
> 5.2 How the schema will represent each document sent to the front end
> 5.3 Separating GDB output and the Inferior output
> 5.4 If GDB recieves commands in XML
>
> Preface
>
> GDB/XMI is meant to be the successor of GDB/MI. It improves upon the
> idea of GDB/MI and fixes many of the known issues that GDB/MI contains.
>
> 1. Introduction
> 1.1 The Problem
>
> Writing a front end for GDB/MI means that a front end has to be able to
> implement an ad hoc parser, capable of understanding all of the data
> sent from GDB to it. For each version of GDB, functionality might change,
> without ever allowing the GUI to understand what the interface differences
> are in a scientific manner. Any guessing from version to version is a
> best-chance scenario, leaving the front end guessing what functionality
> a CVS snapshot has that has been installed on any particular distribution.
>
> 1.2 The Objective
>
> The objective of GDB/XMI is to create a reliable protocol between
> GDB and the front end controlling GDB. A goal of this project is to
> remove most of the parsing from the front end, and move it to a
> reliable parsing library, capable of validating the data it is
> parsing, and building a tree representation of the data without
> any front end infrastructure. It is believed that the protocol between
> GDB and any front end can be automated in every front end and that it
> is not necessary to have any front end developer worry about the syntax
> or grammar of the actual commands sent between GDB and the front end.
>
> Another goal of this project is to formalize the maintenance and
> version management of the XMI commands, as GDB matures, and modifies the
> XMI commands over time. The front end should be independent of the
> XMI command versions, and should be able to determine what data is
> available to it, without worrying about the version of any particular
> XMI command.
>
> It is believed this can help front end writers in several ways. First,
> there will be a significant reduction of time spent in parsing the
> obscure MI commands, and understanding what the output represents.
> This gives front end developers a greater chance of actually getting
> to 1.0 on any given front end, and allowing for much more time to
> be spent on the look & feel of the front end, not including the much
> needed features that most front ends do not have. Secondly, It will
> reduce the code size of each front end, potentially reducing the number
> of bugs, and allowing for a more reliable set of front ends that sit
> on top of GDB.
>
> 2. The GDB/XMI Overview
>
> GDB/XMI is based mostly on the model of GDB/MI. The major differences
> are the need to pass the information from GDB to the front end via XML
> documents and the ability to give the front end a schema, capable
> of validating an XMI command.
>
> 2.1 Passing Information between GDB and the front end
>
> All information passed between GDB and the front end is done in
> the form of an XML document. Each XMI command, generates an XML
> document, and is sent from GDB to the front end.
>
> 2.2 Parsing XMI Commands from GDB's output
>
> XMI is the protocol between GDB and the front end. It is an XML
> based Markup Language that is intended to be the Machine Interface
> between GDB and any application that would like to communicate with it.
>
> An XML document is started and stopped with escape sequences. These
> sequences tell the front end when an XML document is being sent, and
> when the XML document is done being sent. For each XMI command, GDB
> will output an escape sequence saying that it is ready to transmit
> the XML Document response. Then it will output the XML Document. Finally,
> GDB will transmit another escape sequence, saying that the document
> has been completed. This allows the front end to understand what
> information to pass to the XML parser, and what information is output
> from the inferior.
>
> 2.3 Parsing the Inferior's output
>
> When the GDB sends the XML command stating that the inferior has started,
> the front end can then parse the output of GDB waiting for an escape
> sequence, saying that the inferior has stopped running. All of the
> data captured between these two points are output from the inferior.
> It can be processed real time and sent to the user to update them of what
> the inferior is doing. Any asynchronous commands can of course break the
> stream and output data to the front end, and then notify the front end
> that the inferior has started again. This easily allows the front end
> to understand what data is from GDB and what data is from the inferior.
> The only downside to this design is that escape sequences are needed.
> However, the only way to change that is to allow the inferior's output
> to be on a separate communication link (pipe) than the output of GDB.
> So far, this has not happened. Section 5, point 3 illustrates that it
> would be desirable to split GDB's and the inferior's output up, this
> would cause the protocol between GDB and the front end to not include
> the escape sequences before and after each XMI document sent.
>
> 2.4 Validation
> The validation document (DTD) has to be up to date with the XMI
> command for the particular version of GDB. Also, this document has to
> be in one place. Therefore, I propose, that an XMI command be given to
> output to the front end all of the XMI validation documents (DTD?) or
> pass a parameter to have GDB output the validation document for a
> particular XMI command. This document will prove that the XMI commands
> are valid, and GDB is not misbehaving. Front end writers can report
> bad output from GDB easily, and the development process can self-adjust.
>
> The main goal of this tactic is that GDB is capable of telling front ends
> if the output it is generating is correct. Front ends can use this
> capability, at virtually no extra cost, to determine if the protocol
> between the two processes is incorrect. By allowing GDB to keep the
> Schema's, the DRY principle is honored, and things will not get out of
> date.
>
> 2.5 Version Management
>
> From version to version, XMI commands will be modified. Commands will
> be fully backwards compatible, from version to version, allowing only
> fields to be added, or providing more information than is already
> there. The front ends will not have to be updated in this way,
> allowing existing front ends to always be able to use at least the
> amount of information that they have been programmed to understand.
>
> Since it is not a perfect world, it is not always possible to make
> XMI commands backwards compatible. In this case, the XMI command to
> be replaced will be marked as deprecated and a new XMI command will
> be generated to take it's place. This new command will force the
> front end writer to program the functionality of the new command into
> there program, and from then on, will again have a front end capable
> of parsing the new command with a new GDB, and the old command with
> the old GDB.
>
> This model keeps front ends working with both old and new GDB's, which
> is unfortunately a task that most front ends have to and should deal with.
>
> 2.6 Understanding the XML data
>
> Since all commands are backwards compatible, the tree representation
> for any XMI command can be walked the same way, no matter what version
> of the XMI command is being used. The front end is capable of throwing
> away any data that it does not know how or wish to process, allowing
> it to pick and choose what data is appropriate.
>
> 3. GDB/XMI Specification
>
> 3.1 XMI Types
>
> The XMI types are to be used for validation purposes. They can also
> be used to tell the front end what kind of type a particular element
> is that GDB is sending to the front end.
>
> 3.1.1 Scalar Types
>
> <int8> one-byte singed integer
> <uint8> one-byte unsigned integer
> <int16> two-byte signed integer
> <uint16> two-byte unsigned integer
> <int32> four-byte signed integer
> <uint32> four-byte unsigned integer
> <int64> eight-byte signed integer
> <uint64> eight-byte unsigned integer
> <boolean> 0 (false) or 1 (true)
> <string> string
> <float> single-precision signed floating point number
> <double> double-precision signed floating point number
>
> 3.1.2 Compound Types (Structs)
>
> A "struct" is a compound value in which accessor name is the only
> distinction among member values, and no accessor has the same name
> as any other.
>
> <struct_example>
> <element_one>one</element_one>
> <element_two>two</element_two>
> <element_three>three</element_three>
> </struct_example>
>
> A Schema for such a struct could look like this.
>
> <element name="struct_example">
> <complexType>
> <element name="element_one" type="string"/>
> <element name="element_two" type="string"/>
> <element name="element_three" type="string"/>
> </complexType>
> </struct_example>
>
> 3.2 A Breakpoint Listing
>
> 3.2.1 The GDB/MI -break-list Specification
> The -break-list Command
>
> Displays the list of inserted breakpoints, showing the following fields:
>
> `Number'
> number of the breakpoint
> `Type'
> type of the breakpoint: `breakpoint' or `watchpoint'
> `Disposition'
> should the breakpoint be deleted or disabled when it is hit:
> `keep' or `nokeep' `Enabled' is the breakpoint enabled or no:
> `y' or `n'
> `Address'
> memory location at which the breakpoint is set
> `What'
> logical location of the breakpoint, expressed by function name,
> file name, line number
> `Times'
> number of times the breakpoint has been hit
>
> If there are no breakpoints or watchpoints, the BreakpointTable body
> field is an empty list.
>
> 3.2.2 GDB/MI Output
>
> -break-list
> ^done,
> BreakpointTable={
> nr_rows="4",nr_cols="6",
> hdr=[
> {width="3",alignment="-1",col_name="number",colhdr="Num"},
> {width="14",alignment="-1",col_name="type",colhdr="Type"},
> {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
> {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
> {width="10",alignment="-1",col_name="addr",colhdr="Address"},
> {width="40",alignment="2",col_name="what",colhdr="What"}
> ],
> body=[
> bkpt={
> number="1",type="breakpoint",disp="keep",enabled="y",
> addr="0x0804844f",func="main",file="test.c",line="35",times="1"},
> bkpt={
> number="2",type="breakpoint",disp="keep",enabled="y",
> addr="0x080483ef",func="short_func",file="test.c",line="13",times="0"},
> bkpt={
> number="3",type="breakpoint",disp="keep",enabled="y",
> addr="0x0804851d",func="main",file="test.c",line="61",times="0"},
> bkpt={
> number="4",type="hw watchpoint",disp="keep",enabled="y",addr="",
> what="argc",times="0"}
> ]
> }
>
> 3.2.3 The GDB/XMI Output
>
> <?xml version="1.0"?>
> <breakpoints>
> <breakpoint>
> <number>1</number>
> <type>breakpoint</type>
> <disp>keep</disp>
> <enabled>1</enabled>
> <addr>0x0804844f</addr>
> <func>main</func>
> <file>test.c</file>
> <line>35</line>
> <times>0</times>
> </breakpoint>
> <breakpoint>
> <number>2</number>
> <type>breakpoint</type>
> <disp>keep</disp>
> <enabled>1</enabled>
> <addr>0x080483ef</addr>
> <func>short_func</func>
> <file>test.c</file>
> <line>13</line>
> <times>0</times>
> </breakpoint>
> <breakpoint>
> <number>3</number>
> <type>breakpoint</type>
> <disp>keep</disp>
> <enabled>1</enabled>
> <addr>0x0804851d</addr>
> <func>main</func>
> <file>test.c</file>
> <line>61</line>
> <times>0</times>
> </breakpoint>
> <watchpoint>
> <number>4</number>
> <type>watchpoint</type>
> <disp>keep</disp>
> <enabled>1</enabled>
> <addr></addr>
> <what>argc</what>
> <times>0</times>
> </watchpoint>
> </breakpoints>
>
> 3.3 A Backtrace
>
> 3.3.1 The GDB/MI -stack-list-frames Specification
>
> The -stack-list-frames Command
>
> Synopsis: -stack-list-frames [ low-frame high-frame ]
>
> List the frames currently on the stack. For each frame it displays
> the following info:
>
> `level'
> The frame number, 0 being the topmost frame,
> i.e. the innermost function.
> `addr'
> The $pc value for that frame.
> `func'
> Function name.
> `file'
> File name of the source file where the function lives.
> `line'
> Line number corresponding to the $pc.
>
> If invoked without arguments, this command prints a backtrace for
> the whole stack. If given two integer arguments, it shows the frames
> whose levels are between the two arguments (inclusive). If the two
> arguments are equal, it shows the single frame at the corresponding level.
>
> 3.3.2 GDB/MI Output
>
> (gdb)
> -stack-list-frames
> ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file="test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file="test.c",line="54"}]
>
> ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
> file="test.c",line="13"},frame={level="1",addr="0x080484f5",
> func="main",file="test.c",line="54"}]
>
> 3.3.3 The GDB/XMI Output
>
> <?xml version="1.0"?>
> <stack>
> <frame>
> <level>0</level>
> <addr>0x080483ef</addr>
> <func>short_func</func>
> <file>test.c</file>
> <line>13</line>
> </frame>
> <frame>
> <level>1</level>
> <addr>0x080484f5</addr>
> <func>main</func>
> <file>test.c</file>
> <line>54</line>
> </frame>
> </stack>
>
> 4. A GDB/XMI Example
>
> 4.1 The Inferior's Code
> #include <stdio.h>
> int main(int argc, char **argv){
> printf ( "newline\n" e;
> printf ( "nonewline" );
> return 0;
> }
>
> 4.2 GDB/MI Output
> (gdb)
> -exec-run
> ^running
> (gdb)
> newline
> nonewline*stopped,reason="exited-normally"
> (gdb)
>
> 4.3 GDB/XMI Output
> Assuming that the escape sequence is simply \027
> The whitespace is not necessary, and is simply there for presentation.
>
> \027<GDB_DISPLAY_PROMPT>
> (gdb)
> </GDB_DISPLAY_PROMPT>\027
> \027<GDB_WAITING_FOR_COMMAND/>\027
> -exec-run
> \027<GDB_INFERIOR_STARTED/>\027
> newline
> nonewline\027<GDB_INFERIOR_FINISHED/>\027
> \027<GDB_DISPLAY_PROMPT>
> gdb
> </GDB_DISPLAY_PROMPT>\027
> \027<GDB_WAITING_FOR_COMMAND/>\027
>
> 4.4 A Brief Description of the XMI output
>
> 4.4.1 GDB_DISPLAY_PROMPT Document
> The front end receives the document below.
> \027<GDB_DISPLAY_PROMPT>
> (gdb)
> </GDB_DISPLAY_PROMPT>\027
> The front end sends the data to the XML processor, which then tells
> it that the current prompt is "(gdb) ". The front end can choose to
> do whatever it wants with this information, including display it to the
> user, or just ignore it.
>
> 4.4.2 GDB_WAITING_FOR_COMMAND Document
> Next, GDB transmits the document below.
> \027<GDB_WAITING_FOR_COMMAND/>\027
> The front end receives the data and sends it to the XML processor. The
> processor parses the document and the front end can determine that
> the command says that GDB is ready to accept a user command. At this
> point, the front end understands that it is OK to transmit a command to
> GDB.
>
> 4.4.3 The Front End Transmits a Command
> The front end transmits the command "-exec-run".
> Should the front end transmit commands in XML or just
> ordinary text?
>
> 4.4.4 GDB_INFERIOR_STARTED Document
> GDB would send a document telling the front end that the inferior
> has begun processing.
> \027<GDB_INFERIOR_STARTED/>\027
> Everything the front end processes from the pipe from this point
> until the next GDB XMI Document transmission is from the inferior.
> It is considered to be output that the inferior would like to have
> the user see. The front end can process this data realtime, since
> it does not have to be sent to the XML parser for processing.
>
> The data
> newline
> nonewline
> is outputted by the inferior, and the front end processes this data
> realtime, understanding that it is not the output of GDB.
>
> 4.4.5 GDB_INFERIOR_FINISHED Document
> GDB would send a document telling the front end that the inferior
> has finished processing.
> \027<GDB_INFERIOR_FINISHED/>\027
>
> This alerts the front end that GDB is now outputting XMI commands
> again. The front end no longer expects information from the inferior.
> Optionally, GDB could output a XMI command stating that a signal
> has been caught, or some other asynchronous event has occurred. This
> could be something like
> \027<GDB_SIGNAL_CAUGHT>
> <SIGNAL>
> <NAME>SIGINT</NAME>
> <NUMBER>2</NUMBER>
> <COMMENT>Interrupt from keyboard</COMMENT>
> </SIGNAL>
> </GDB_SIGNAL_CAUGHT>\027
> In this way, GDB could alert the front end of any asynchronous event,
> and no special parsing mechanism will have to take place to
> understand such actions.
>
> 5. Issues to resolve after RFC Initial approval.
>
> 5.1 If GDB will link to libxml, or just output XML
> It would be nice if GDB was capable of sending the XML documents by
> creating them via libxml. However, libxml2 is licensed under the
> MIT license. Also, I don't know if libxml2 is as portable as GDB.
>
> 5.2 How the schema will represent each document sent to the front end
> If there will be one schema for each XMI document, or a schema
> that represents every XMI document.
>
> 5.3 Separating GDB output and the Inferior output
> If GDB can output it's data on a different pipe than the
> inferior then the escape sequences would not be needed to tell
> the front end which data is from GDB and which is from the inferior.
>
> This would simply the front end processing.
>
> 5.4 If GDB recieves commands in XML
> If GDB links in libxml2, then it could easy receive commands from the
> front end in XML. This would be a nice feature, although, since the
> parser in GDB is only written once, it doesn't really matter what format
> the commands are that is sent to it.
>
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: GDB/XMI (XML Machine Interface)
2004-08-10 20:14 GDB/XMI (XML Machine Interface) Bob Rossi
2004-08-10 22:38 ` Kip Macy
@ 2004-08-11 0:17 ` Michael Chastain
2004-08-11 7:36 ` Fabian Cenedese
` (3 subsequent siblings)
5 siblings, 0 replies; 212+ messages in thread
From: Michael Chastain @ 2004-08-11 0:17 UTC (permalink / raw)
To: gdb, bob
Interesting idea. Here are my opinions. This is real armchair stuff,
I've not an MI expert, but I've had a little experience with XML
(my test bed uses XML headers to track the hundreds of configurations
that I generate and test). So these opinions are naive.
Pro XML:
Standard libraries are available for reading XML. This moves one
level of parsing out of front end code into a standard library.
DTD helps solve the versioning problem.
Con XML:
MI already exists.
XML standardizes some of the lowest levels of the data interchange format.
But I get the impression that the problems you have are not at that level.
They are really one level up. Problems like:
. The MI has an insufficient reflective interface. That is, the front end
cannot query GDB and find out the list of supported commands and the
format of each command. With XML, gdb could support commands to get
the list of supported commands and a DTD for each command.
. MI output changes from time to time. Your proposal is to restrict
the changes: fields can be added but not removed or modified;
commands can be added and old commands deprecated. I think this
sort of protocol evolution is XML-neutral, it's the same kind of
restrictions whatever the data format.
. Inferior process output mixes with gdb output. I don't think XML
helps with this at all -- it's a problem at a lower level than the
XML level. Either open several streams, or emit some kind of packets
on the single stream, with each packet tagged as "gdb output" or
"inferior output". XML is not very good for interpolating
"inferior output" at random places in the XML stream.
From a higher view, adopting XML would force us to think about these
issues. If a program writes XML then it's natural to expect the XML to
match some DTD, and then you start thinking about versioning the DTD,
and so on. It's a cultural environment where the requirements that come
from the front end are a natural part of this environment.
As far as I can tell, and I'm no expert on MI, we could do most of these
things with the existing MI interface. Separating inferior output from
gdb output is a different kind of problem, no matter what the data
interchange format. But the reflective interface and the protocol
evolution could be done with MI.
We could identify the requirements and then make MI meet those
requirements, without going to XML data interchange format. Or,
conversely, if we're having trouble with MI fields changing too much in
cvs gdb, then we're also at risk from the DTD changing too much in an
XML-based MI.
Michael C
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: GDB/XMI (XML Machine Interface)
2004-08-10 20:14 GDB/XMI (XML Machine Interface) Bob Rossi
2004-08-10 22:38 ` Kip Macy
2004-08-11 0:17 ` Michael Chastain
@ 2004-08-11 7:36 ` Fabian Cenedese
2004-08-11 8:51 ` Nick NoSpam
` (2 subsequent siblings)
5 siblings, 0 replies; 212+ messages in thread
From: Fabian Cenedese @ 2004-08-11 7:36 UTC (permalink / raw)
To: gdb
> GDB/XMI (XML Machine Interface)
>
> 3.2.1 The GDB/MI -break-list Specification
> The -break-list Command
>
> Displays the list of inserted breakpoints, showing the following fields:
>
> `Number'
> number of the breakpoint
> `Type'
> type of the breakpoint: `breakpoint' or `watchpoint'
> `Disposition'
> should the breakpoint be deleted or disabled when it is hit:
> `keep' or `nokeep' `Enabled' is the breakpoint enabled or no:
> `y' or `n'
> `Address'
> memory location at which the breakpoint is set
> `What'
> logical location of the breakpoint, expressed by function name,
> file name, line number
> `Times'
> number of times the breakpoint has been hit
>
> If there are no breakpoints or watchpoints, the BreakpointTable body
> field is an empty list.
I think there should be an additional field for the task id, indicating if it's
a general breakpoint (id=-1 or so) or a task-specific breakpoint.
bye Fabi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: GDB/XMI (XML Machine Interface)
2004-08-10 20:14 GDB/XMI (XML Machine Interface) Bob Rossi
` (2 preceding siblings ...)
2004-08-11 7:36 ` Fabian Cenedese
@ 2004-08-11 8:51 ` Nick NoSpam
2004-08-11 18:05 ` Bob Rossi
2004-08-19 23:49 ` Bob Rossi
5 siblings, 0 replies; 212+ messages in thread
From: Nick NoSpam @ 2004-08-11 8:51 UTC (permalink / raw)
To: Bob Rossi; +Cc: gdb
First I'd like to commend you on the initiative to do something about
the MI problems. I too have fiddled w/ a frontend and aun into a slew
of problems w/ MI2 (some of which made their way into the bug tracker
months ago w/out any attention). I also have a great deal of experience
w/ XML (have used it for years and continue to do so at my job).
Now for the real honesty: I don't think an XML interface is going to
fix the real problem.
Disclaimer: I'm not an expert at GDB (it's internals nor usage) or GDB
MI. The following is my candid opinion--it's too late (technically
early) to be tactful.
The real problem is that GDB is not a library. It's a fairly convoluted
mess that uses the console as it's primary interface. That is wrong.
All abstractions and extensions (including MI*) work through the
console--essentially automating a user's keystrokes. And there lies the
fundamental problem: all methods of offering more than the console
interface are subject to the pitfalls of a console interface. Michael
Chastain points out a popular one: distinguishing GDB output from
inferior output.
What's worse, GDB has been massaged over time to be a one-size-fits-all
solution (ie. tightly coupled). That's also wrong. The problems of
which are evident when one tries to add or modify significant
functionality.
The time spent to generate a well-defined XML interface won't provide
much more than spending the same time improving the MI2 interface
(perhaps yielding MI3). But neither of these approaches solves the real
problem outlined above.
So I think the best (and proper) thing to do is work on splitting GDB
into a separate, well-defined library. Then, all interfaces (including
the console) are simply clients to this library. At that time, an XML
interface would go further (as it adds language independence and
remoting).
A quick google search tells me I'm not the only one w/ this idea. I
don't necessarily agree w/ the design of Andrew Cagney's libGDB, but the
idea is spot on:
http://sources.redhat.com/gdb/papers/libgdb2/
Regards,
Nick G.
On Tue, 2004-08-10 at 16:14, Bob Rossi wrote:
> Hi,
>
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
>
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
>
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to
> sit on top of GDB. This will at least give the community one open
> source front end to GDB and an example to prove that the new
> machine interface works.
>
> I can't wait to hear your opinions/comments.
>
> Thanks,
> Bob Rossi
>
> GDB/XMI (XML Machine Interface)
>
> Robert Rossi
> August 2004
> bob@brasko.net
>
>
> TABLE OF CONTENTS
>
> 1. Introduction
> 1.1 The Problem
> 1.2 The Objective
>
> 2. The GDB/XMI Overview
> 2.1 Passing Information between GDB and the front end
> 2.2 Parsing XMI Commands from GDB's output
> 2.3 Parsing the Inferior's output
> 2.4 Validation
> 2.5 Version Management
> 2.6 Understanding the XML data
>
> 3. GDB/XMI Specification
> 3.1 XMI Types
> 3.1.1 Scalar Types
> 3.1.2 Compound Types (Structs)
> 3.2 A Breakpoint Listing
> 3.2.1 The GDB/MI -break-list Specification
> 3.2.2 GDB/MI Output
> 3.2.3 The GDB/XMI Output
> 3.3 A Backtrace
> 3.3.1 The GDB/MI -stack-list-frames Specification
> 3.3.2 GDB/MI Output
> 3.3.3 The GDB/XMI Output
>
> 4. A GDB/XMI Example
> 4.1 The Inferior's Code
> 4.2 GDB/MI Output
> 4.3 GDB/XMI Output
> 4.4 A Brief Description of the XMI output
> 4.4.1 GDB_DISPLAY_PROMPT Document
> 4.4.2 GDB_WAITING_FOR_COMMAND Document
> 4.4.3 The Front End Transmits a Command
> 4.4.4 GDB_INFERIOR_STARTED Document
> 4.4.5 GDB_INFERIOR_FINISHED Document
>
> 5. Issues to resolve after RFC Initial approval.
> 5.1 If GDB will link to libxml, or just output XML
> 5.2 How the schema will represent each document sent to the front end
> 5.3 Separating GDB output and the Inferior output
> 5.4 If GDB recieves commands in XML
>
> Preface
>
> GDB/XMI is meant to be the successor of GDB/MI. It improves upon the
> idea of GDB/MI and fixes many of the known issues that GDB/MI contains.
>
> 1. Introduction
> 1.1 The Problem
>
> Writing a front end for GDB/MI means that a front end has to be able to
> implement an ad hoc parser, capable of understanding all of the data
> sent from GDB to it. For each version of GDB, functionality might change,
> without ever allowing the GUI to understand what the interface differences
> are in a scientific manner. Any guessing from version to version is a
> best-chance scenario, leaving the front end guessing what functionality
> a CVS snapshot has that has been installed on any particular distribution.
>
> 1.2 The Objective
>
> The objective of GDB/XMI is to create a reliable protocol between
> GDB and the front end controlling GDB. A goal of this project is to
> remove most of the parsing from the front end, and move it to a
> reliable parsing library, capable of validating the data it is
> parsing, and building a tree representation of the data without
> any front end infrastructure. It is believed that the protocol between
> GDB and any front end can be automated in every front end and that it
> is not necessary to have any front end developer worry about the syntax
> or grammar of the actual commands sent between GDB and the front end.
>
> Another goal of this project is to formalize the maintenance and
> version management of the XMI commands, as GDB matures, and modifies the
> XMI commands over time. The front end should be independent of the
> XMI command versions, and should be able to determine what data is
> available to it, without worrying about the version of any particular
> XMI command.
>
> It is believed this can help front end writers in several ways. First,
> there will be a significant reduction of time spent in parsing the
> obscure MI commands, and understanding what the output represents.
> This gives front end developers a greater chance of actually getting
> to 1.0 on any given front end, and allowing for much more time to
> be spent on the look & feel of the front end, not including the much
> needed features that most front ends do not have. Secondly, It will
> reduce the code size of each front end, potentially reducing the number
> of bugs, and allowing for a more reliable set of front ends that sit
> on top of GDB.
>
> 2. The GDB/XMI Overview
>
> GDB/XMI is based mostly on the model of GDB/MI. The major differences
> are the need to pass the information from GDB to the front end via XML
> documents and the ability to give the front end a schema, capable
> of validating an XMI command.
>
> 2.1 Passing Information between GDB and the front end
>
> All information passed between GDB and the front end is done in
> the form of an XML document. Each XMI command, generates an XML
> document, and is sent from GDB to the front end.
>
> 2.2 Parsing XMI Commands from GDB's output
>
> XMI is the protocol between GDB and the front end. It is an XML
> based Markup Language that is intended to be the Machine Interface
> between GDB and any application that would like to communicate with it.
>
> An XML document is started and stopped with escape sequences. These
> sequences tell the front end when an XML document is being sent, and
> when the XML document is done being sent. For each XMI command, GDB
> will output an escape sequence saying that it is ready to transmit
> the XML Document response. Then it will output the XML Document. Finally,
> GDB will transmit another escape sequence, saying that the document
> has been completed. This allows the front end to understand what
> information to pass to the XML parser, and what information is output
> from the inferior.
>
> 2.3 Parsing the Inferior's output
>
> When the GDB sends the XML command stating that the inferior has started,
> the front end can then parse the output of GDB waiting for an escape
> sequence, saying that the inferior has stopped running. All of the
> data captured between these two points are output from the inferior.
> It can be processed real time and sent to the user to update them of what
> the inferior is doing. Any asynchronous commands can of course break the
> stream and output data to the front end, and then notify the front end
> that the inferior has started again. This easily allows the front end
> to understand what data is from GDB and what data is from the inferior.
> The only downside to this design is that escape sequences are needed.
> However, the only way to change that is to allow the inferior's output
> to be on a separate communication link (pipe) than the output of GDB.
> So far, this has not happened. Section 5, point 3 illustrates that it
> would be desirable to split GDB's and the inferior's output up, this
> would cause the protocol between GDB and the front end to not include
> the escape sequences before and after each XMI document sent.
>
> 2.4 Validation
> The validation document (DTD) has to be up to date with the XMI
> command for the particular version of GDB. Also, this document has to
> be in one place. Therefore, I propose, that an XMI command be given to
> output to the front end all of the XMI validation documents (DTD?) or
> pass a parameter to have GDB output the validation document for a
> particular XMI command. This document will prove that the XMI commands
> are valid, and GDB is not misbehaving. Front end writers can report
> bad output from GDB easily, and the development process can self-adjust.
>
> The main goal of this tactic is that GDB is capable of telling front ends
> if the output it is generating is correct. Front ends can use this
> capability, at virtually no extra cost, to determine if the protocol
> between the two processes is incorrect. By allowing GDB to keep the
> Schema's, the DRY principle is honored, and things will not get out of
> date.
>
> 2.5 Version Management
>
> From version to version, XMI commands will be modified. Commands will
> be fully backwards compatible, from version to version, allowing only
> fields to be added, or providing more information than is already
> there. The front ends will not have to be updated in this way,
> allowing existing front ends to always be able to use at least the
> amount of information that they have been programmed to understand.
>
> Since it is not a perfect world, it is not always possible to make
> XMI commands backwards compatible. In this case, the XMI command to
> be replaced will be marked as deprecated and a new XMI command will
> be generated to take it's place. This new command will force the
> front end writer to program the functionality of the new command into
> there program, and from then on, will again have a front end capable
> of parsing the new command with a new GDB, and the old command with
> the old GDB.
>
> This model keeps front ends working with both old and new GDB's, which
> is unfortunately a task that most front ends have to and should deal with.
>
> 2.6 Understanding the XML data
>
> Since all commands are backwards compatible, the tree representation
> for any XMI command can be walked the same way, no matter what version
> of the XMI command is being used. The front end is capable of throwing
> away any data that it does not know how or wish to process, allowing
> it to pick and choose what data is appropriate.
>
> 3. GDB/XMI Specification
>
> 3.1 XMI Types
>
> The XMI types are to be used for validation purposes. They can also
> be used to tell the front end what kind of type a particular element
> is that GDB is sending to the front end.
>
> 3.1.1 Scalar Types
>
> <int8> one-byte singed integer
> <uint8> one-byte unsigned integer
> <int16> two-byte signed integer
> <uint16> two-byte unsigned integer
> <int32> four-byte signed integer
> <uint32> four-byte unsigned integer
> <int64> eight-byte signed integer
> <uint64> eight-byte unsigned integer
> <boolean> 0 (false) or 1 (true)
> <string> string
> <float> single-precision signed floating point number
> <double> double-precision signed floating point number
>
> 3.1.2 Compound Types (Structs)
>
> A "struct" is a compound value in which accessor name is the only
> distinction among member values, and no accessor has the same name
> as any other.
>
> <struct_example>
> <element_one>one</element_one>
> <element_two>two</element_two>
> <element_three>three</element_three>
> </struct_example>
>
> A Schema for such a struct could look like this.
>
> <element name="struct_example">
> <complexType>
> <element name="element_one" type="string"/>
> <element name="element_two" type="string"/>
> <element name="element_three" type="string"/>
> </complexType>
> </struct_example>
>
> 3.2 A Breakpoint Listing
>
> 3.2.1 The GDB/MI -break-list Specification
> The -break-list Command
>
> Displays the list of inserted breakpoints, showing the following fields:
>
> `Number'
> number of the breakpoint
> `Type'
> type of the breakpoint: `breakpoint' or `watchpoint'
> `Disposition'
> should the breakpoint be deleted or disabled when it is hit:
> `keep' or `nokeep' `Enabled' is the breakpoint enabled or no:
> `y' or `n'
> `Address'
> memory location at which the breakpoint is set
> `What'
> logical location of the breakpoint, expressed by function name,
> file name, line number
> `Times'
> number of times the breakpoint has been hit
>
> If there are no breakpoints or watchpoints, the BreakpointTable body
> field is an empty list.
>
> 3.2.2 GDB/MI Output
>
> -break-list
> ^done,
> BreakpointTable={
> nr_rows="4",nr_cols="6",
> hdr=[
> {width="3",alignment="-1",col_name="number",colhdr="Num"},
> {width="14",alignment="-1",col_name="type",colhdr="Type"},
> {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
> {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
> {width="10",alignment="-1",col_name="addr",colhdr="Address"},
> {width="40",alignment="2",col_name="what",colhdr="What"}
> ],
> body=[
> bkpt={
> number="1",type="breakpoint",disp="keep",enabled="y",
> addr="0x0804844f",func="main",file="test.c",line="35",times="1"},
> bkpt={
> number="2",type="breakpoint",disp="keep",enabled="y",
> addr="0x080483ef",func="short_func",file="test.c",line="13",times="0"},
> bkpt={
> number="3",type="breakpoint",disp="keep",enabled="y",
> addr="0x0804851d",func="main",file="test.c",line="61",times="0"},
> bkpt={
> number="4",type="hw watchpoint",disp="keep",enabled="y",addr="",
> what="argc",times="0"}
> ]
> }
>
> 3.2.3 The GDB/XMI Output
>
> <?xml version="1.0"?>
> <breakpoints>
> <breakpoint>
> <number>1</number>
> <type>breakpoint</type>
> <disp>keep</disp>
> <enabled>1</enabled>
> <addr>0x0804844f</addr>
> <func>main</func>
> <file>test.c</file>
> <line>35</line>
> <times>0</times>
> </breakpoint>
> <breakpoint>
> <number>2</number>
> <type>breakpoint</type>
> <disp>keep</disp>
> <enabled>1</enabled>
> <addr>0x080483ef</addr>
> <func>short_func</func>
> <file>test.c</file>
> <line>13</line>
> <times>0</times>
> </breakpoint>
> <breakpoint>
> <number>3</number>
> <type>breakpoint</type>
> <disp>keep</disp>
> <enabled>1</enabled>
> <addr>0x0804851d</addr>
> <func>main</func>
> <file>test.c</file>
> <line>61</line>
> <times>0</times>
> </breakpoint>
> <watchpoint>
> <number>4</number>
> <type>watchpoint</type>
> <disp>keep</disp>
> <enabled>1</enabled>
> <addr></addr>
> <what>argc</what>
> <times>0</times>
> </watchpoint>
> </breakpoints>
>
> 3.3 A Backtrace
>
> 3.3.1 The GDB/MI -stack-list-frames Specification
>
> The -stack-list-frames Command
>
> Synopsis: -stack-list-frames [ low-frame high-frame ]
>
> List the frames currently on the stack. For each frame it displays
> the following info:
>
> `level'
> The frame number, 0 being the topmost frame,
> i.e. the innermost function.
> `addr'
> The $pc value for that frame.
> `func'
> Function name.
> `file'
> File name of the source file where the function lives.
> `line'
> Line number corresponding to the $pc.
>
> If invoked without arguments, this command prints a backtrace for
> the whole stack. If given two integer arguments, it shows the frames
> whose levels are between the two arguments (inclusive). If the two
> arguments are equal, it shows the single frame at the corresponding level.
>
> 3.3.2 GDB/MI Output
>
> (gdb)
> -stack-list-frames
> ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file="test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file="test.c",line="54"}]
>
> ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",
> file="test.c",line="13"},frame={level="1",addr="0x080484f5",
> func="main",file="test.c",line="54"}]
>
> 3.3.3 The GDB/XMI Output
>
> <?xml version="1.0"?>
> <stack>
> <frame>
> <level>0</level>
> <addr>0x080483ef</addr>
> <func>short_func</func>
> <file>test.c</file>
> <line>13</line>
> </frame>
> <frame>
> <level>1</level>
> <addr>0x080484f5</addr>
> <func>main</func>
> <file>test.c</file>
> <line>54</line>
> </frame>
> </stack>
>
> 4. A GDB/XMI Example
>
> 4.1 The Inferior's Code
> #include <stdio.h>
> int main(int argc, char **argv){
> printf ( "newline\n" e;
> printf ( "nonewline" );
> return 0;
> }
>
> 4.2 GDB/MI Output
> (gdb)
> -exec-run
> ^running
> (gdb)
> newline
> nonewline*stopped,reason="exited-normally"
> (gdb)
>
> 4.3 GDB/XMI Output
> Assuming that the escape sequence is simply \027
> The whitespace is not necessary, and is simply there for presentation.
>
> \027<GDB_DISPLAY_PROMPT>
> (gdb)
> </GDB_DISPLAY_PROMPT>\027
> \027<GDB_WAITING_FOR_COMMAND/>\027
> -exec-run
> \027<GDB_INFERIOR_STARTED/>\027
> newline
> nonewline\027<GDB_INFERIOR_FINISHED/>\027
> \027<GDB_DISPLAY_PROMPT>
> gdb
> </GDB_DISPLAY_PROMPT>\027
> \027<GDB_WAITING_FOR_COMMAND/>\027
>
> 4.4 A Brief Description of the XMI output
>
> 4.4.1 GDB_DISPLAY_PROMPT Document
> The front end receives the document below.
> \027<GDB_DISPLAY_PROMPT>
> (gdb)
> </GDB_DISPLAY_PROMPT>\027
> The front end sends the data to the XML processor, which then tells
> it that the current prompt is "(gdb) ". The front end can choose to
> do whatever it wants with this information, including display it to the
> user, or just ignore it.
>
> 4.4.2 GDB_WAITING_FOR_COMMAND Document
> Next, GDB transmits the document below.
> \027<GDB_WAITING_FOR_COMMAND/>\027
> The front end receives the data and sends it to the XML processor. The
> processor parses the document and the front end can determine that
> the command says that GDB is ready to accept a user command. At this
> point, the front end understands that it is OK to transmit a command to
> GDB.
>
> 4.4.3 The Front End Transmits a Command
> The front end transmits the command "-exec-run".
> Should the front end transmit commands in XML or just
> ordinary text?
>
> 4.4.4 GDB_INFERIOR_STARTED Document
> GDB would send a document telling the front end that the inferior
> has begun processing.
> \027<GDB_INFERIOR_STARTED/>\027
> Everything the front end processes from the pipe from this point
> until the next GDB XMI Document transmission is from the inferior.
> It is considered to be output that the inferior would like to have
> the user see. The front end can process this data realtime, since
> it does not have to be sent to the XML parser for processing.
>
> The data
> newline
> nonewline
> is outputted by the inferior, and the front end processes this data
> realtime, understanding that it is not the output of GDB.
>
> 4.4.5 GDB_INFERIOR_FINISHED Document
> GDB would send a document telling the front end that the inferior
> has finished processing.
> \027<GDB_INFERIOR_FINISHED/>\027
>
> This alerts the front end that GDB is now outputting XMI commands
> again. The front end no longer expects information from the inferior.
> Optionally, GDB could output a XMI command stating that a signal
> has been caught, or some other asynchronous event has occurred. This
> could be something like
> \027<GDB_SIGNAL_CAUGHT>
> <SIGNAL>
> <NAME>SIGINT</NAME>
> <NUMBER>2</NUMBER>
> <COMMENT>Interrupt from keyboard</COMMENT>
> </SIGNAL>
> </GDB_SIGNAL_CAUGHT>\027
> In this way, GDB could alert the front end of any asynchronous event,
> and no special parsing mechanism will have to take place to
> understand such actions.
>
> 5. Issues to resolve after RFC Initial approval.
>
> 5.1 If GDB will link to libxml, or just output XML
> It would be nice if GDB was capable of sending the XML documents by
> creating them via libxml. However, libxml2 is licensed under the
> MIT license. Also, I don't know if libxml2 is as portable as GDB.
>
> 5.2 How the schema will represent each document sent to the front end
> If there will be one schema for each XMI document, or a schema
> that represents every XMI document.
>
> 5.3 Separating GDB output and the Inferior output
> If GDB can output it's data on a different pipe than the
> inferior then the escape sequences would not be needed to tell
> the front end which data is from GDB and which is from the inferior.
>
> This would simply the front end processing.
>
> 5.4 If GDB recieves commands in XML
> If GDB links in libxml2, then it could easy receive commands from the
> front end in XML. This would be a nice feature, although, since the
> parser in GDB is only written once, it doesn't really matter what format
> the commands are that is sent to it.
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: GDB/XMI (XML Machine Interface)
2004-08-10 20:14 GDB/XMI (XML Machine Interface) Bob Rossi
` (3 preceding siblings ...)
2004-08-11 8:51 ` Nick NoSpam
@ 2004-08-11 18:05 ` Bob Rossi
2004-08-11 19:26 ` Alain Magloire
2004-08-19 23:49 ` Bob Rossi
5 siblings, 1 reply; 212+ messages in thread
From: Bob Rossi @ 2004-08-11 18:05 UTC (permalink / raw)
To: gdb
Hi,
Thanks to everyone that has looked at this RFC so far. I will leave the idea
floating around for a few days to let everyone have a chance to
respond. Then I will follow up the RFC with a summary of everyone's
opinions.
I can see with the ideas given already, that if everyone contributes
(at least informationally), this RFC could be modified to fit into GDB
very nicely.
Thanks,
Bob Rossi
On Tue, Aug 10, 2004 at 04:14:40PM -0400, Bob Rossi wrote:
> Hi,
>
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
>
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
>
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to
> sit on top of GDB. This will at least give the community one open
> source front end to GDB and an example to prove that the new
> machine interface works.
>
> I can't wait to hear your opinions/comments.
>
> Thanks,
> Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: GDB/XMI (XML Machine Interface)
2004-08-11 18:05 ` Bob Rossi
@ 2004-08-11 19:26 ` Alain Magloire
2004-08-11 22:35 ` Jason Molenda
0 siblings, 1 reply; 212+ messages in thread
From: Alain Magloire @ 2004-08-11 19:26 UTC (permalink / raw)
To: Bob Rossi; +Cc: gdb
>
> Hi,
>
> Thanks to everyone that has looked at this RFC so far. I will leave the idea
> floating around for a few days to let everyone have a chance to
> respond. Then I will follow up the RFC with a summary of everyone's
> opinions.
>
> I can see with the ideas given already, that if everyone contributes
> (at least informationally), this RFC could be modified to fit into GDB
> very nicely.
>
Nick "No spam" G. and other said something about this already .. I'll just reiterate.
The problem is not so much MI as a protocol then the implementation of MI in gdb 8-).
If you read the MI spec, it is not that bad .. actually very promising
and with the proposed changes from Andrew C and crew .. not bad at all.
MI did offer a consistent parsing vs protocol like Annoted {1,2}
Reality check, it hits you like a brick wall: the grand canyon between the documentation
vs actual implementation.
(some third parties like WindRiver or Apple seems to have "cleaner" implementation of MI).
Doing a clean recursive decent parser for MI, is actually very simple...
it's just that you have to make n exceptions: inconsitencies, plain bugs,
crap etc .. the inferior output can be intertwine to the protocol, the duality CLI vs MI in an IDE,
the OOB(async notifications) being incomplete, the inconsistensies between argument parsing etc ..
Pros:
No doubt, XMI will offer an even more consistent parsing, it is a well know and formal language.
So the parsing will no longer be the focus (with all the available xml parsers) of problems.
The focus will be shift to more consistency of the data and folks can concentrate on
real issues(can we get notification for loading of dll or catch event implementation 8-) etc .. a good thing.
But whether XMI or MI the problems remains; a good implementation and resources to work on it.
GDB carries in its belly an enormous knowledge an heritage but that makes it also obese 8-(
most folks prefer to go around problems with yet another rewrite instead of digging in ...
Question: are you doing the same with this XMI proposal ? If yes you'll fall to the same trap
as MI and GDB will carry "yet another incomplete implementation" 8-)
Note:
don't get me wrong the RFC is pretty good, and for a Java programer, xml is pure symphony.
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: GDB/XMI (XML Machine Interface)
2004-08-11 19:26 ` Alain Magloire
@ 2004-08-11 22:35 ` Jason Molenda
2004-08-12 13:03 ` Nick NoSpam
0 siblings, 1 reply; 212+ messages in thread
From: Jason Molenda @ 2004-08-11 22:35 UTC (permalink / raw)
To: Alain Magloire; +Cc: Bob Rossi, gdb
Hi Alain,
On Aug 11, 2004, at 12:26 PM, Alain Magloire wrote:
> Doing a clean recursive decent parser for MI, is actually very
> simple...
> it's just that you have to make n exceptions: inconsitencies, plain
> bugs,
> crap etc .. the inferior output can be intertwine to the protocol, the
> duality CLI vs MI in an IDE, the OOB(async notifications) being
> incomplete, the inconsistensies between argument parsing etc ..
I think both Chris and Jim mentioned this already, but it's easy to
separate inferior I/O from the MI command stream. The UI sets up a
pseudo tty that it controls and uses the gdb "tty" command to redirect
inferior I/O to that ptty. Our Xcode UI has been using this technique
for at least a couple of years now.
Jason
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: GDB/XMI (XML Machine Interface)
2004-08-11 22:35 ` Jason Molenda
@ 2004-08-12 13:03 ` Nick NoSpam
0 siblings, 0 replies; 212+ messages in thread
From: Nick NoSpam @ 2004-08-12 13:03 UTC (permalink / raw)
To: Jason Molenda; +Cc: Alain Magloire, Bob Rossi, gdb
> it's easy to separate inferior I/O from the MI command stream.
Certainly there are methods, but the MI2 spec clearly defines how this
situation should be handled. Apparently this is not a new issue, so
when MI2 was defined, inferior output was specifically handled via it's
own syntax. So the problem is implementation (see bug 1654 from May).
XML format won't cure this situation.
Regards,
Nick G.
On Wed, 2004-08-11 at 18:35, Jason Molenda wrote:
> Hi Alain,
>
> On Aug 11, 2004, at 12:26 PM, Alain Magloire wrote:
>
> > Doing a clean recursive decent parser for MI, is actually very
> > simple...
> > it's just that you have to make n exceptions: inconsitencies, plain
> > bugs,
> > crap etc .. the inferior output can be intertwine to the protocol, the
> > duality CLI vs MI in an IDE, the OOB(async notifications) being
> > incomplete, the inconsistensies between argument parsing etc ..
>
>
> I think both Chris and Jim mentioned this already, but it's easy to
> separate inferior I/O from the MI command stream. The UI sets up a
> pseudo tty that it controls and uses the gdb "tty" command to redirect
> inferior I/O to that ptty. Our Xcode UI has been using this technique
> for at least a couple of years now.
>
> Jason
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: GDB/XMI (XML Machine Interface)
2004-08-10 20:14 GDB/XMI (XML Machine Interface) Bob Rossi
` (4 preceding siblings ...)
2004-08-11 18:05 ` Bob Rossi
@ 2004-08-19 23:49 ` Bob Rossi
2004-08-20 7:09 ` Chris Friesen
5 siblings, 1 reply; 212+ messages in thread
From: Bob Rossi @ 2004-08-19 23:49 UTC (permalink / raw)
To: gdb
On Tue, Aug 10, 2004 at 04:14:40PM -0400, Bob Rossi wrote:
> Hi,
>
> As most of you know, I have been writing a front end to GDB called CGDB.
> However, for a while now, I have been a little disappointed with the MI
> interface. In my RFC I have described the problems I have with MI and I
> have proposed a new method of communication between GDB and the front
> end.
>
> If there is good feedback on this RFC, I will continue research on it,
> filling in details that I thought would be best to wait until after an
> initial acceptance.
>
> If the RFC is accepted by the community I plan on implementing an
> initial version of the XMI interface in GDB, and programming CGDB to
> sit on top of GDB. This will at least give the community one open
> source front end to GDB and an example to prove that the new
> machine interface works.
>
> I can't wait to hear your opinions/comments.
Hi,
Well, it seems as if my efforts only brought up enough interest to just
get a couple of replies.
Basically, most of you point out that I am interested in changing at a high
level the development process of the interface between GDB and the front end.
Obviously, switching GDB's output to XML only gains the front ends a simple
way to parse the data. Besides validation, and maybe transformations, it
basically does nothing else. I have listed some other higher level things, like
Michael pointed out. These are the things that I feel will make my front end
successful over the long run. I understand that what makes my front end
successful might not make everyone's successful, but the union of all these
ideas will make everyone's front end successful. Therefor, I am offering up
at least the minimum amount of work that needs to be done to GDB in order to
make a front end successful, not just now, but in the future also.
Michael noted some of the things I think a protocol should contain
. The MI has an insufficient reflective interface.
. MI output changes from time to time. Your proposal is to restrict
the changes: fields can be added but not removed or modified;
commands can be added and old commands deprecated.
. Inferior process output mixes with gdb output.
All of these issues are key to what I think a front end should expect from
GDB. However, I realize that none of these issues have anything to do with
XML. XML is just an obvious way to communicate data between to entities.
Jim suggested,
1) You can run gdb and use the tty command to send inferior output to a
separate pty.
2) The XML output should just be another ui_out.
and some suggestions on commands sent from the front end to GDB.
Nick G suggested,
Now for the real honesty: I don't think an XML interface is going to
fix the real problem. The real problem is that GDB is not a library.
Chris F suggested,
He defiantly didn't see the benefit to switching to XMI, since XML is harder
for him to understand than MI output.
I don't really know where to go from here. The XML change I think is a no brainer.
It is a task that every front end writer in the future will be thankful for. Believe me,
no one is interested in parsing the MI output. It is a *complete waste of time*.
Next and more importantly, the versioning is a major hurdle for me in regards to MI.
I think protocols should always be backwards compatible, it is a necessity for the
client of the protocol. However, up till now I might be the only one making a big stink
out of this, and therefor the versions are not backwards compatible. I believe CVS
snapshots and major releases should always adhere to the backwards compatibility test.
For example, I use CGDB with a version of GNAT's GDB and it works because A2 hasn't
changed. I want to be able to use XMI with a 4 year old GDB, because the software world
is majorly screwed up, and sometimes I find myself having to work with ancient software.
If this document could be modified in any way, I would be more than glad to make an
initial effort at getting GDB/XMI going. I believe that all of the infrastructure for
the MI commands can stay in place, and like Jim said, a new ui_out could be created.
A re-write from the MI is the worst idea in my opinion. I think that GDB is finally
maturing a protocol that front end developers can not snicker at. I believe it should just
be modified in some ways and that XML would be a great plus for outputting data.
Finally, the difference between a text based protocol and a libgdb interface is irrelevant
to me. I would personally prefer the text based protocol at this point in time seeing that
there is no libgdb. What stopped the production of that effort? Also, making clients link
to the GDB they want to work with seems like a pain.
My proposal would be to make all of the infrastructure change to the MI code, not new code.
Add validation, versioning, and maybe a new way besides the tty command to separate
GDB output and the inferior output. Finally, add a new ui_out that outputs the commands in
XML. Thus, only adding the XML feature completely, otherwise, changing the process's of the
MI to work the way I am suggesting.
Eagerly awaiting instructions :)
Thanks,
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: GDB/XMI (XML Machine Interface)
2004-08-19 23:49 ` Bob Rossi
@ 2004-08-20 7:09 ` Chris Friesen
2004-08-20 12:47 ` Bob Rossi
0 siblings, 1 reply; 212+ messages in thread
From: Chris Friesen @ 2004-08-20 7:09 UTC (permalink / raw)
To: gdb
On Aug 19, 2004, at 4:49 PM, Bob Rossi wrote:
<whack>
>
> Chris F suggested,
> He defiantly didn't see the benefit to switching to XMI, since XML
> is harder
> for him to understand than MI output.
That's uncharitable, try:
Didn't see a big benefit in using one structured data format over
the other. All things being equal, finds pages of MI easier to read
than the order of magnitude longer output that XML would be.
> I don't really know where to go from here. The XML change I think is a
> no brainer.
<snip>
>
> Finally, the difference between a text based protocol and a libgdb
> interface is irrelevant
> to me. I would personally prefer the text based protocol at this point
> in time seeing that
> there is no libgdb. What stopped the production of that effort?
Did license issues prevent adoption? I know that would likely keep me
from being able to use a libgdb. Yeah, yeah dry your eyes. ;-)
Go for the Gold,
-ChrisF
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: GDB/XMI (XML Machine Interface)
2004-08-20 7:09 ` Chris Friesen
@ 2004-08-20 12:47 ` Bob Rossi
0 siblings, 0 replies; 212+ messages in thread
From: Bob Rossi @ 2004-08-20 12:47 UTC (permalink / raw)
To: gdb
On Fri, Aug 20, 2004 at 12:09:25AM -0700, Chris Friesen wrote:
>
> On Aug 19, 2004, at 4:49 PM, Bob Rossi wrote:
> <whack>
> >
> >Chris F suggested,
> > He defiantly didn't see the benefit to switching to XMI, since XML
> >is harder
> > for him to understand than MI output.
>
> That's uncharitable, try:
> Didn't see a big benefit in using one structured data format over
> the other. All things being equal, finds pages of MI easier to read
> than the order of magnitude longer output that XML would be.
I'm sorry, I worded that bad, didn't I? I did not mean "understand" as
in comprehend, anyways, thanks for correcting me.
> >I don't really know where to go from here. The XML change I think is a
> >no brainer.
> <snip>
> >
> >Finally, the difference between a text based protocol and a libgdb
> >interface is irrelevant
> >to me. I would personally prefer the text based protocol at this point
> >in time seeing that
> >there is no libgdb. What stopped the production of that effort?
>
> Did license issues prevent adoption? I know that would likely keep me
> from being able to use a libgdb. Yeah, yeah dry your eyes. ;-)
Good point.
Bob Rossi
^ permalink raw reply [flat|nested] 212+ messages in thread
* RE: breaking at for-loop test line
@ 2004-07-29 13:07 Atul Talesara
0 siblings, 0 replies; 212+ messages in thread
From: Atul Talesara @ 2004-07-29 13:07 UTC (permalink / raw)
To: Allen Hopkins, gdb
First of all, my apologies for the length of the reply,
but I thought of taking a inter-mixeded code to assist
the explanation.
One-liner explanation:
When breakpoint is placed at line 7, it corresponds
to the first instruction before beginning of the
for(...)loop, which happens to be the initialization,
hence breakpoint there is hit only once.
For those who are eager for detailed explanation,
can go ahead:
Though the gdb/gcc versions are not relevant for this
discussion, I'm producing them for completeness:
gcc version 3.2
GNU gdb 5.2.1-4 for "i386-redhat-linux"
>
> 1 #include <iostream.h>
> 2
> 3 int main(int argc, char* argv[])
> 4 {
> 5 int i = 0;
> 6
> 7 for (i = 0; i < 3; i++) {
> 8 cout << i << endl;
> 9 }
> 10
> 11 while (i < 6) {
> 12 cout << i++ << endl;
> 13 }
> 14
> 15 exit(0);
> 16 }
>
> If I set a breakpoint at line 7, and another at line 11,
> and "run" and "continue" until exit, it will only break once
> on the for-loop, but it will break on each iteration of the
> while-loop. How does this make sense? Is there any way to
> get a breakpoint at the top of the for-loop to act like the
> while-loop?
Well, when you set the breakpoint at the line of for (...) loop
the break is placed on the instruction which initializes
your loop variable, 'i' in this case.
Here's the edited inter-mixed code:
------------
# objdump -S s.out
int main(int argc, char* argv[])
{
8048608: push %ebp
...
for (i = 0; i < 3; i++) {
804861f: movl $0x0,0xfffffffc(%ebp)
8048626: cmpl $0x2,0xfffffffc(%ebp)
cout << i << endl;
804862e: sub $0x8,%esp
...
8048657: jmp 8048626 <main+0x1e>
while (i < 6) {
804865a: cmpl $0x5,0xfffffffc(%ebp)
...
cout << i++ << endl;
8048662: sub $0x8,%esp
...
8048689: add $0x10,%esp
804868c: jmp 804865a <main+0x52>
------------
And here's the GDB session:
------------
(gdb) b 7
Breakpoint 1 at 0x804861f: file test.cpp, line 7.
(gdb) b 11
Breakpoint 2 at 0x804865a: file test.cpp, line 11.
------------
So if you see carefully, the breakpoint is placed at the
address "0x804861f" which corresponds to
"movl $0x0,0xfffffffc(%ebp)" which is nothing but the
initialization of for() loop "i=0" which is bound to
execute only *once* for the life of the program.
(See the jump at the end of for (..) loop: 0x8048657,
this jumps to "0x8048626" and your break was address
above that!)
On other hand if you see for while() loop, break is placed
at "0x804865a" which corresponds to the comparison instruction:
"cmpl $0x5,0xfffffffc(%ebp)" which is bound to execute
*every time* we loop to the beginning of while().
(See the jump at end of while loop: 0x804868c,
this jumps to "0x804865a" where your break is placed!)
Yes, you guessed it right ...
If you skip the initialization part in the for(...) loop,
you will get the breakpoint behaviour exactly like your
while(...) loop! Here's the mixed-disassembly snippet:
--------
# objdump -S s.out
int main(int argc, char* argv[])
{
8048608: push %ebp
...
for (; i < 3; i++) {
804861f: cmpl $0x2,0xfffffffc(%ebp)
...
cout << i << endl;
8048627: sub $0x8,%esp
...
8048650: jmp 804861f <main+0x17>
GDB Session:
(gdb) b 7
Breakpoint 1 at 0x804861f: file s.cpp, line 7.
--------
In this case the jump at the end of for() loop
(0x8048650) corresponds to the condition of the
for() loop (0x804861f) and the breakpoint at line
7 indeed behaves like break on while().
Hope the breakpoint behaviour now makes sense :-)
Allen, you can check the same with your platform,
I don't have access to Sol box.
Regards,
Atul P Talesara
----------------------------------------------------------
Begin with an End in mind.
----------------------------------------------------------
^ permalink raw reply [flat|nested] 212+ messages in thread
* [proposal/testsuite] require build == host
@ 2004-07-25 1:18 Michael Chastain
2004-07-25 1:52 ` Felix Lee
` (2 more replies)
0 siblings, 3 replies; 212+ messages in thread
From: Michael Chastain @ 2004-07-25 1:18 UTC (permalink / raw)
To: gdb
I'm working on a test script for the 'edit' command. In order to test
the 'edit' command, the test script has to manage files on the host
machine (where gdb is running), not the build machine (where dejagnu is
running).
A recapitulation:
build runs dejagnu and the *.exp scripts
host runs gcc, as, ld, and gdb
target runs the test program such as "callfuncs" or "structs2"
I started looking at how other gdb test scripts work in a configuration
where build and host are different machines, and, well, they don't.
There are about a dozen scripts that compile test files with header
files, and except for list.exp, none of them download their *.h files to
the host machine. gcore.exp manipulates files that gdb creates on the
host machine. It needs to "remote upload" the files that gdb creates
back to the build machine, but it doesn't. And so on.
Of course the test suite supports a target machine which is separate
from the build/host machine. That is not at issue.
I don't think anyone actually uses a configuration with separate build
and host. So I propose this patch to document that the gdb test suite
requires that build and host be the same machine.
I'll give this proposal a week for discussion. I'm hoping that the
discussion goes "you're right, build-cross-host is silly and
unnecessary, just drop it already", but someone may have a good reason
for wanting it.
Testing: I built gdbint.texinfo with makeinfo 4.7 to check the syntax.
But that's not really important yet. This is about the proposal,
not about the specific patch.
Comments?
Michael C
2004-07-24 Michael Chastain <mec.gnu@mindspring.com>
* gdbint.texinfo (Testsuite): Document that build and host
must be the same machine.
Index: gdbint.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v
retrieving revision 1.214
diff -c -3 -p -r1.214 gdbint.texinfo
*** gdbint.texinfo 1 Jul 2004 20:25:54 -0000 1.214
--- gdbint.texinfo 25 Jul 2004 00:01:08 -0000
*************** difficult to test, such as code that han
*** 6315,6320 ****
--- 6315,6325 ----
in particular versions of compilers, and it's OK not to try to write
tests for all of those.
+ DejaGNU supports separate build, host, and target machines. However,
+ the @value{GDBN} testsuite requires that the host machine be the
+ same as the build machine. This requirement simplifies the writing
+ of test files.
+
@section Testsuite Organization
@cindex test suite organization
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: [proposal/testsuite] require build == host
2004-07-25 1:18 [proposal/testsuite] require build == host Michael Chastain
@ 2004-07-25 1:52 ` Felix Lee
2004-07-25 2:43 ` Daniel Jacobowitz
2004-07-25 7:59 ` [proposal/testsuite] require build == host Eli Zaretskii
2004-07-27 0:45 ` Andrew Cagney
2 siblings, 1 reply; 212+ messages in thread
From: Felix Lee @ 2004-07-25 1:52 UTC (permalink / raw)
To: Michael Chastain; +Cc: gdb
mec.gnu@mindspring.com (Michael Chastain):
> I don't think anyone actually uses a configuration with separate build
> and host. So I propose this patch to document that the gdb test suite
> requires that build and host be the same machine.
hm. gdb runs on more systems than expect does, and my feeling at
the moment is that it's sometimes easier to do build!=host
testing than it is to get expect running, like on weird embedded
linux devices.
not that I particularly like the testsuite complications added by
build!=host, but I don't know a better alternative yet.
--
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: [proposal/testsuite] require build == host
2004-07-25 1:52 ` Felix Lee
@ 2004-07-25 2:43 ` Daniel Jacobowitz
[not found] ` <drow@false.org>
0 siblings, 1 reply; 212+ messages in thread
From: Daniel Jacobowitz @ 2004-07-25 2:43 UTC (permalink / raw)
To: Felix Lee; +Cc: Michael Chastain, gdb
On Sat, Jul 24, 2004 at 06:18:16PM -0700, Felix Lee wrote:
> mec.gnu@mindspring.com (Michael Chastain):
> > I don't think anyone actually uses a configuration with separate build
> > and host. So I propose this patch to document that the gdb test suite
> > requires that build and host be the same machine.
>
> hm. gdb runs on more systems than expect does, and my feeling at
> the moment is that it's sometimes easier to do build!=host
> testing than it is to get expect running, like on weird embedded
> linux devices.
>
> not that I particularly like the testsuite complications added by
> build!=host, but I don't know a better alternative yet.
Have you ever actually needed to do this?
When I tested GDB on embedded Linux devices, expect was not the issue.
Expect is easy if you have enough RAM footprint to fit a GDB binary!
Also, what is a host on which GDB works but expect does not?
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: [proposal/testsuite] require build == host
2004-07-25 1:18 [proposal/testsuite] require build == host Michael Chastain
2004-07-25 1:52 ` Felix Lee
@ 2004-07-25 7:59 ` Eli Zaretskii
2004-07-27 0:45 ` Andrew Cagney
2 siblings, 0 replies; 212+ messages in thread
From: Eli Zaretskii @ 2004-07-25 7:59 UTC (permalink / raw)
To: Michael Chastain; +Cc: gdb
> Date: Sat, 24 Jul 2004 20:03:44 -0400 (EDT)
> From: mec.gnu@mindspring.com (Michael Chastain)
>
> 2004-07-24 Michael Chastain <mec.gnu@mindspring.com>
>
> * gdbint.texinfo (Testsuite): Document that build and host
> must be the same machine.
I don't have an opinion about the issue, but the patch is okay with
me, provided that we agree to the requirement itself.
Perhaps this paragraph should be indexed, though: it sounds important
enough to warrant that.
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: [proposal/testsuite] require build == host
2004-07-25 1:18 [proposal/testsuite] require build == host Michael Chastain
2004-07-25 1:52 ` Felix Lee
2004-07-25 7:59 ` [proposal/testsuite] require build == host Eli Zaretskii
@ 2004-07-27 0:45 ` Andrew Cagney
2004-07-27 2:31 ` Michael Chastain
2 siblings, 1 reply; 212+ messages in thread
From: Andrew Cagney @ 2004-07-27 0:45 UTC (permalink / raw)
To: Michael Chastain; +Cc: gdb
What do the dejagnu maintainers have to say about the feature? I can on
the one hand see it being abandoned while on the other hand being used
for something like parallel testing?
As for a system that would/should use this - djgpp.
Andrew
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: [proposal/testsuite] require build == host
2004-07-27 0:45 ` Andrew Cagney
@ 2004-07-27 2:31 ` Michael Chastain
2004-07-27 4:16 ` Eli Zaretskii
2004-07-27 15:32 ` Andrew Cagney
0 siblings, 2 replies; 212+ messages in thread
From: Michael Chastain @ 2004-07-27 2:31 UTC (permalink / raw)
To: cagney; +Cc: gdb
ac> What do the dejagnu maintainers have to say about the feature?
I haven't asked, but it's a supported feature of dejagnu and I'm
willing to accept that they will keep on supporting it.
Dan Kegel is at least one user of dejagnu who uses build != host
with gcc. He wrote a whole section in his cross-gcc faq about it.
People are testing gcc with dejagnu using build != host,
so it would be good if gdb testing worked in the same environment.
ac> As for a system that would/should use this - djgpp.
You got me there. It's been a while since I used windows,
but I suspect that windows has telnet/ftp servers.
Eli, is it possible to ftp into a windows box and upload and
download files? More important, is it possible to telnet into
a windows box and run a command-line interpreter?
It looks like I should go with Plan B: file PR's against the
test scripts that don't work on build != host, and eventually
fix them.
Michael C
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: [proposal/testsuite] require build == host
2004-07-27 2:31 ` Michael Chastain
@ 2004-07-27 4:16 ` Eli Zaretskii
2004-07-27 15:32 ` Andrew Cagney
1 sibling, 0 replies; 212+ messages in thread
From: Eli Zaretskii @ 2004-07-27 4:16 UTC (permalink / raw)
To: Michael Chastain; +Cc: cagney, gdb
> Date: Mon, 26 Jul 2004 20:52:26 -0400
> From: Michael Chastain <mec.gnu@mindspring.com>
>
> ac> As for a system that would/should use this - djgpp.
>
> You got me there. It's been a while since I used windows,
> but I suspect that windows has telnet/ftp servers.
(Btw, DJGPP produces DOS programs, not Windows programs. These
programs do run on Windows, but Windows treats them as DOS
executables.)
> Eli, is it possible to ftp into a windows box and upload and
> download files? More important, is it possible to telnet into
> a windows box and run a command-line interpreter?
It is possible to do that on Windows XP (perhaps after enabling some
service that is off by default, I don't remember).
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: [proposal/testsuite] require build == host
2004-07-27 2:31 ` Michael Chastain
2004-07-27 4:16 ` Eli Zaretskii
@ 2004-07-27 15:32 ` Andrew Cagney
2004-07-27 15:50 ` Christopher Faylor
2004-07-27 21:17 ` Michael Chastain
1 sibling, 2 replies; 212+ messages in thread
From: Andrew Cagney @ 2004-07-27 15:32 UTC (permalink / raw)
To: Michael Chastain; +Cc: gdb
> ac> What do the dejagnu maintainers have to say about the feature?
>
> I haven't asked, but it's a supported feature of dejagnu and I'm
> willing to accept that they will keep on supporting it.
It would be useful, just so that we know where they are going.
> Dan Kegel is at least one user of dejagnu who uses build != host
> with gcc. He wrote a whole section in his cross-gcc faq about it.
> People are testing gcc with dejagnu using build != host,
> so it would be good if gdb testing worked in the same environment.
>
> ac> As for a system that would/should use this - djgpp.
>
> You got me there. It's been a while since I used windows,
> but I suspect that windows has telnet/ftp servers.
>
> Eli, is it possible to ftp into a windows box and upload and
> download files? More important, is it possible to telnet into
> a windows box and run a command-line interpreter?
This is how the original cygwin testing was done - at a dos prompt.
> It looks like I should go with Plan B: file PR's against the
> test scripts that don't work on build != host, and eventually
> fix them.
For the moment, lets stick with the status quo. Tests are required to
work host==build. Having a test work host!=build is an added bonus, but
not a requrement. We can hardly enforce host!=build when there's no way
to test it and the return on investment is marginal.
Andrew
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: [proposal/testsuite] require build == host
2004-07-27 15:32 ` Andrew Cagney
@ 2004-07-27 15:50 ` Christopher Faylor
2004-07-27 21:17 ` Michael Chastain
1 sibling, 0 replies; 212+ messages in thread
From: Christopher Faylor @ 2004-07-27 15:50 UTC (permalink / raw)
To: gdb
On Tue, Jul 27, 2004 at 11:14:20AM -0400, Andrew Cagney wrote:
>>Eli, is it possible to ftp into a windows box and upload and download
>>files? More important, is it possible to telnet into a windows box and
>>run a command-line interpreter?
>
>This is how the original cygwin testing was done - at a dos prompt.
Right. And the test suite shennanigans necessary to support this were
truly ugly and, for some tests, only worked randomly.
>>It looks like I should go with Plan B: file PR's against the test
>>scripts that don't work on build != host, and eventually fix them.
>
>For the moment, lets stick with the status quo. Tests are required to
>work host==build. Having a test work host!=build is an added bonus,
>but not a requrement. We can hardly enforce host!=build when there's
>no way to test it and the return on investment is marginal.
FWIW, I agree.
cgf
^ permalink raw reply [flat|nested] 212+ messages in thread
* Re: [proposal/testsuite] require build == host
2004-07-27 15:32 ` Andrew Cagney
2004-07-27 15:50 ` Christopher Faylor
@ 2004-07-27 21:17 ` Michael Chastain
1 sibling, 0 replies; 212+ messages in thread
From: Michael Chastain @ 2004-07-27 21:17 UTC (permalink / raw)
To: cagney; +Cc: gdb
ac> It would be useful, just so that we know where they are going.
I talked to Rob Savoye a month or two ago, and basically
Dejagnu is mature at this point. I don't think it's going to
add or drop major features.
ac> For the moment, lets stick with the status quo. Tests are required to
ac> work host==build. Having a test work host!=build is an added bonus, but
ac> not a requrement. We can hardly enforce host!=build when there's no way
ac> to test it and the return on investment is marginal.
The machine resources are easy to get. build == my laptop,
host == hp test drive machine (they support inbound telnet and ftp).
All I have to do is write a board file!
I'm going to move off the status quo in one direction or the other.
Either build != host is supported, or it's not. If it is supported,
then I have to test it (sigh), and at least characterize how many tests
are broken. If it's not supported, then I want the doco to say so.
Michael C
^ permalink raw reply [flat|nested] 212+ messages in thread
end of thread, other threads:[~2005-10-10 23:53 UTC | newest]
Thread overview: 212+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-07-29 5:10 breaking at for-loop test line Allen Hopkins
2004-07-29 16:29 ` Daniel Jacobowitz
2004-07-29 18:58 ` Andre Ancelin
2004-07-30 11:32 ` Eli Zaretskii
2004-08-03 19:21 ` Daniel Jacobowitz
2004-08-03 20:09 ` Andrew Cagney
2004-08-03 20:21 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2005-10-10 20:46 Laziness David Lecomber
2005-10-10 20:50 ` Laziness Daniel Jacobowitz
2005-10-10 21:05 ` Laziness David Lecomber
2005-10-10 21:09 ` Laziness Daniel Jacobowitz
2005-10-10 21:24 ` Laziness David Lecomber
2005-10-10 21:27 ` Laziness Daniel Jacobowitz
2005-10-10 23:53 ` Laziness Paul Hilfinger
[not found] <200508292030.NAA29909@hpsje.cup.hp.com>
[not found] ` <1125360166.9350.69.camel@aretha.corp.specifix.com>
2005-08-30 1:13 ` HP gdb/wdb sources available Daniel Jacobowitz
2005-08-30 2:13 ` Paul Hilfinger
2004-10-26 14:49 backtrace changes current source location Felix Lee
2004-10-28 13:49 ` Daniel Jacobowitz
2004-10-06 1:03 Bumping MI protocol Bob Rossi
2004-10-06 5:08 ` Nathan J. Williams
2004-10-06 11:27 ` Bob Rossi
2004-10-06 12:30 ` Eli Zaretskii
2004-10-06 16:38 ` Bob Rossi
2004-10-06 16:45 ` Nathan J. Williams
2004-10-06 19:53 ` Bob Rossi
[not found] ` <eliz@gnu.org>
2004-10-06 16:57 ` Felix Lee
2004-10-06 17:03 ` Bob Rossi
2004-10-04 17:51 gdbserver, sysroot, prelink Felix Lee
2004-10-04 18:12 ` Daniel Jacobowitz
2004-10-03 17:15 probing GDB for MI versions Bob Rossi
2004-10-04 9:00 ` Eli Zaretskii
2004-10-04 13:19 ` Bob Rossi
2004-10-05 9:10 ` Eli Zaretskii
2004-10-05 12:34 ` Bob Rossi
2004-10-06 10:19 ` Eli Zaretskii
2004-10-06 11:47 ` Bob Rossi
2004-10-06 12:13 ` Dave Korn
2004-10-06 16:31 ` 'Bob Rossi'
2004-10-06 16:46 ` Nathan J. Williams
2004-10-06 16:55 ` 'Bob Rossi'
2004-10-06 17:04 ` Nathan J. Williams
2004-10-06 17:15 ` 'Bob Rossi'
2004-10-06 16:57 ` Dave Korn
2004-10-06 17:12 ` 'Bob Rossi'
2004-10-06 17:21 ` Dave Korn
2004-10-06 17:24 ` 'Bob Rossi'
2004-10-06 17:31 ` Daniel Jacobowitz
2004-10-06 17:38 ` Bob Rossi
2004-10-06 17:41 ` Dave Korn
2004-10-06 17:55 ` 'Bob Rossi'
2004-10-06 18:19 ` Paul Koning
2004-10-07 10:56 ` Dave Korn
2004-10-07 14:15 ` 'Bob Rossi'
2004-10-07 14:28 ` Dave Korn
2004-10-07 14:37 ` 'Bob Rossi'
2004-10-07 14:39 ` Dave Korn
2004-10-07 14:50 ` 'Bob Rossi'
2004-10-07 15:38 ` Dave Korn
2004-10-07 15:49 ` 'Bob Rossi'
2004-10-07 16:31 ` Nathan J. Williams
2004-10-07 16:45 ` Alain Magloire
2004-10-07 17:12 ` Dave Korn
[not found] ` <200410071614.MAA19648@smtp.ott.qnx.com>
2004-10-08 6:56 ` 'Bob Rossi'
2004-10-08 9:10 ` Eli Zaretskii
2004-10-10 18:13 ` 'Bob Rossi'
2004-10-11 17:46 ` 'Bob Rossi'
2004-10-13 12:14 ` 'Bob Rossi'
2004-10-13 12:48 ` Eli Zaretskii
2004-10-13 14:05 ` 'Bob Rossi'
2004-10-14 7:10 ` Eli Zaretskii
2004-10-14 19:34 ` 'Bob Rossi'
2004-10-14 21:23 ` Andrew Cagney
2004-10-15 15:40 ` 'Bob Rossi'
2004-10-15 13:02 ` Eli Zaretskii
2004-10-15 13:28 ` Michael Chastain
2004-10-15 13:42 ` Eli Zaretskii
2004-10-15 18:04 ` 'Bob Rossi'
2004-10-16 15:46 ` Eli Zaretskii
2004-10-16 21:56 ` 'Bob Rossi'
2004-10-17 18:59 ` Eli Zaretskii
2004-10-19 13:51 ` 'Bob Rossi'
2004-10-19 14:18 ` Daniel Jacobowitz
2004-10-19 19:28 ` Bob Rossi
2004-10-19 20:17 ` Eli Zaretskii
2004-10-06 18:43 ` Andrew Cagney
2004-10-06 18:54 ` 'Bob Rossi'
2004-10-06 19:19 ` Andrew Cagney
2004-10-06 19:25 ` 'Bob Rossi'
2004-10-06 17:36 ` Dave Korn
2004-10-06 17:51 ` Paul Koning
2004-10-06 18:09 ` Bob Rossi
2004-10-06 17:05 ` Alain Magloire
2004-10-06 19:16 ` Andrew Cagney
2004-10-06 19:20 ` Bob Rossi
2004-10-06 20:10 ` Alain Magloire
2004-10-06 20:15 ` Bob Rossi
2004-10-06 20:13 ` Andrew Cagney
2004-10-08 10:28 ` Eli Zaretskii
2004-10-08 18:48 ` Daniel Jacobowitz
[not found] <5956F1E2-EB0D-11D8-9949-000A9569836A@apple.com>
2004-08-11 0:51 ` GDB/XMI (XML Machine Interface) Chris Friesen
[not found] ` <gdb001@speakeasy.net>
2004-08-11 6:28 ` Felix Lee
2004-08-11 8:25 ` Chris Friesen
2004-08-11 22:43 ` Felix Lee
2004-08-12 4:54 ` OT: " Chris Friesen
2004-08-20 10:34 ` Felix Lee
2004-08-20 12:54 ` Bob Rossi
2004-08-20 18:34 ` Daniel Jacobowitz
2004-08-20 18:49 ` Bob Rossi
2004-08-20 18:52 ` Daniel Jacobowitz
2004-08-20 19:25 ` Bob Rossi
2004-08-20 19:42 ` Daniel Jacobowitz
2004-08-20 19:59 ` Bob Rossi
2004-08-21 10:25 ` Eli Zaretskii
2004-08-21 12:34 ` Bob Rossi
2004-08-21 13:34 ` Eli Zaretskii
[not found] ` <bob@brasko.net>
2004-08-20 18:20 ` Felix Lee
2004-08-20 21:34 ` Felix Lee
2004-08-21 19:21 ` Felix Lee
2004-08-21 20:21 ` Bob Rossi
2004-08-21 19:28 ` Felix Lee
2004-08-21 20:16 ` Bob Rossi
2004-08-21 21:28 ` Felix Lee
2004-08-21 22:37 ` Felix Lee
2004-10-03 18:36 ` GDB/MI snapshots between major release's Felix Lee
2004-10-03 18:40 ` Bob Rossi
2004-10-03 18:42 ` Daniel Jacobowitz
2004-10-03 19:35 ` Bob Rossi
2004-10-03 19:39 ` Felix Lee
2004-10-03 20:19 ` Bob Rossi
2004-10-04 5:00 ` Felix Lee
2004-10-04 15:34 ` Felix Lee
2004-10-04 15:58 ` Bob Rossi
2004-10-04 16:48 ` Felix Lee
2004-10-04 17:37 ` Bob Rossi
2004-10-04 18:31 ` Felix Lee
2004-10-04 19:00 ` Bob Rossi
2004-10-04 21:07 ` Felix Lee
2004-10-03 17:01 ` Bob Rossi
2004-10-04 5:04 ` Eli Zaretskii
2004-10-04 14:59 ` Bob Rossi
2004-10-04 15:49 ` Mark Kettenis
2004-10-04 16:04 ` Bob Rossi
2004-10-05 10:57 ` Eli Zaretskii
2004-10-05 14:18 ` Daniel Jacobowitz
2004-10-06 1:40 ` Bob Rossi
2004-10-06 11:14 ` Eli Zaretskii
2004-10-06 11:39 ` Bob Rossi
2004-10-06 13:19 ` Eli Zaretskii
2004-10-06 16:55 ` Bob Rossi
2004-10-06 17:00 ` Paul Koning
2004-10-06 17:02 ` Bob Rossi
2004-10-04 21:27 ` Daniel Jacobowitz
2004-10-04 22:14 ` Bob Rossi
2004-10-05 9:03 ` Fabian Cenedese
2004-10-05 9:18 ` Eli Zaretskii
2004-10-05 13:37 ` Bob Rossi
2004-10-05 18:53 ` probing GDB for MI versions Felix Lee
2004-10-06 17:14 ` GDB/MI snapshots between major release's Felix Lee
2004-10-06 17:21 ` Daniel Jacobowitz
2004-10-06 18:41 ` Felix Lee
2004-10-06 18:50 ` Bob Rossi
2004-10-06 18:55 ` Bumping MI protocol Felix Lee
2004-10-06 19:43 ` Bob Rossi
2004-10-06 21:04 ` Felix Lee
2004-10-07 18:01 ` probing GDB for MI versions Felix Lee
2004-10-07 19:44 ` Bob Rossi
2004-10-08 8:54 ` Fabian Cenedese
2004-10-19 20:13 ` Felix Lee
2004-10-19 20:23 ` Eli Zaretskii
2004-10-19 21:27 ` Bob Rossi
2004-11-09 2:27 ` Bob Rossi
2004-08-10 20:14 GDB/XMI (XML Machine Interface) Bob Rossi
2004-08-10 22:38 ` Kip Macy
2004-08-11 0:17 ` Michael Chastain
2004-08-11 7:36 ` Fabian Cenedese
2004-08-11 8:51 ` Nick NoSpam
2004-08-11 18:05 ` Bob Rossi
2004-08-11 19:26 ` Alain Magloire
2004-08-11 22:35 ` Jason Molenda
2004-08-12 13:03 ` Nick NoSpam
2004-08-19 23:49 ` Bob Rossi
2004-08-20 7:09 ` Chris Friesen
2004-08-20 12:47 ` Bob Rossi
2004-07-29 13:07 breaking at for-loop test line Atul Talesara
2004-07-25 1:18 [proposal/testsuite] require build == host Michael Chastain
2004-07-25 1:52 ` Felix Lee
2004-07-25 2:43 ` Daniel Jacobowitz
[not found] ` <drow@false.org>
2004-07-25 22:36 ` Felix Lee
2004-07-26 18:07 ` Michael Chastain
2004-07-27 4:41 ` Felix Lee
2004-07-29 22:21 ` breaking at for-loop test line Felix Lee
2004-07-30 8:23 ` Baurjan Ismagulov
[not found] ` <ibr@ata.cs.hun.edu.tr>
2004-07-30 10:46 ` Felix Lee
2004-08-03 18:53 ` Daniel Jacobowitz
2004-08-20 19:06 ` GDB/XMI (XML Machine Interface) Felix Lee
2004-08-20 19:09 ` Daniel Jacobowitz
2004-08-20 19:20 ` Felix Lee
2004-08-21 12:37 ` Bob Rossi
2004-10-04 19:05 ` gdbserver, sysroot, prelink Felix Lee
2004-10-04 19:24 ` Daniel Jacobowitz
2004-10-05 13:03 ` Andrew Cagney
2004-10-05 13:52 ` Daniel Jacobowitz
2004-10-05 13:53 ` Felix Lee
2004-10-06 17:58 ` GDB/MI snapshots between major release's Felix Lee
2004-10-29 8:32 ` backtrace changes current source location Felix Lee
2004-07-25 7:59 ` [proposal/testsuite] require build == host Eli Zaretskii
2004-07-27 0:45 ` Andrew Cagney
2004-07-27 2:31 ` Michael Chastain
2004-07-27 4:16 ` Eli Zaretskii
2004-07-27 15:32 ` Andrew Cagney
2004-07-27 15:50 ` Christopher Faylor
2004-07-27 21:17 ` Michael Chastain
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).