MI -break-info command issues

MI -break-info command issues

[Vladimir Prus]

Hello!

Playing with MI -break-info command with gdb 6.4, I notice two issues.

1. The command does not print the full name (i.e. absolute) of the file
where the breakpoint is. That is pretty bad for integrating with GUIs. Did
I miss some other command? Is there a way to get full name of the file?

2. The output of the command looks like this:
^done,BreakpointTable={nr_rows="1",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="2",type="breakpoint",disp="keep",enabled="y",
addr="0x08048464",func="main",file="main.cpp",line="6",times="1"}]}

What is the point of producing spreadsheet-like output with columns and
column heading and column alignment? I'd expect that any GUI frontend will
have some specific representation and just ignore that extra formatting.
Why generate it at all?

- Volodya

Re: MI -break-info command issues

[Bob Rossi]

On Tue, Jan 24, 2006 at 05:16:49PM +0300, Vladimir Prus wrote:
> 
> Hello!
> 
> Playing with MI -break-info command with gdb 6.4, I notice two issues.
> 
> 1. The command does not print the full name (i.e. absolute) of the file
> where the breakpoint is. That is pretty bad for integrating with GUIs. Did
> I miss some other command? Is there a way to get full name of the file?

You can use -file-list-exec-source-file and
-file-list-exec-source-files. However, I thought someone already added
the fullname to the breakpoint output. Try CVS. If they have not, this 
would be an obvious improvement and patches are welcome.

2. The output of the command looks like this:
> ^done,BreakpointTable={nr_rows="1",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="2",type="breakpoint",disp="keep",enabled="y",
> addr="0x08048464",func="main",file="main.cpp",line="6",times="1"}]}
> 
> What is the point of producing spreadsheet-like output with columns and
> column heading and column alignment? I'd expect that any GUI frontend will
> have some specific representation and just ignore that extra formatting.
> Why generate it at all?

I agree, this output has always been useless to me. I would be happy to
see it go away.

Bob Rossi

Re: MI -break-info command issues

[Vladimir Prus]

On Tuesday 24 January 2006 17:44, Bob Rossi wrote:

> > Playing with MI -break-info command with gdb 6.4, I notice two issues.
> >
> > 1. The command does not print the full name (i.e. absolute) of the file
> > where the breakpoint is. That is pretty bad for integrating with GUIs.
> > Did I miss some other command? Is there a way to get full name of the
> > file?
>
> You can use -file-list-exec-source-file and
> -file-list-exec-source-files. 
> However, I thought someone already added 
> the fullname to the breakpoint output. Try CVS. 

No, still not fullname in CVS.

> If they have not, this 
> would be an obvious improvement and patches are welcome.

Understood.

- Volodya

Re: MI -break-info command issues

[Eli Zaretskii]

> Date: Tue, 24 Jan 2006 09:44:49 -0500
> From: Bob Rossi <bob@brasko.net>
> Cc: gdb@sources.redhat.com
> 
> 2. The output of the command looks like this:
> > ^done,BreakpointTable={nr_rows="1",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="2",type="breakpoint",disp="keep",enabled="y",
> > addr="0x08048464",func="main",file="main.cpp",line="6",times="1"}]}
> > 
> > What is the point of producing spreadsheet-like output with columns and
> > column heading and column alignment? I'd expect that any GUI frontend will
> > have some specific representation and just ignore that extra formatting.
> > Why generate it at all?
> 
> I agree, this output has always been useless to me. I would be happy to
> see it go away.

I DON'T agree, and I think it would be a grave mistake to have this
output go away.  About the worst thing a program can do is have some
information and not reveal it.  Skipping unneeded information is easy;
restoring missing one is next to impossible.

Re: MI -break-info command issues

[Bob Rossi]

On Tue, Jan 24, 2006 at 10:49:59PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 24 Jan 2006 09:44:49 -0500
> > From: Bob Rossi <bob@brasko.net>
> > Cc: gdb@sources.redhat.com
> > 
> > 2. The output of the command looks like this:
> > > ^done,BreakpointTable={nr_rows="1",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="2",type="breakpoint",disp="keep",enabled="y",
> > > addr="0x08048464",func="main",file="main.cpp",line="6",times="1"}]}
> > > 
> > > What is the point of producing spreadsheet-like output with columns and
> > > column heading and column alignment? I'd expect that any GUI frontend will
> > > have some specific representation and just ignore that extra formatting.
> > > Why generate it at all?
> > 
> > I agree, this output has always been useless to me. I would be happy to
> > see it go away.
> 
> I DON'T agree, and I think it would be a grave mistake to have this
> output go away.  About the worst thing a program can do is have some
> information and not reveal it.  Skipping unneeded information is easy;
> restoring missing one is next to impossible.

Like I said, I don't understand why this information is important. 
The breakpoint command is the only one that get's a header, and I 
find it odd.

However, if you would like it to stay, I won't get in your way.

Bob Rossi

Re: MI -break-info command issues

[Vladimir Prus]

Eli Zaretskii wrote:

>> Date: Tue, 24 Jan 2006 09:44:49 -0500
>> From: Bob Rossi <bob@brasko.net>
>> Cc: gdb@sources.redhat.com
>> 
>> 2. The output of the command looks like this:
>> > ^done,BreakpointTable={nr_rows="1",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="2",type="breakpoint",disp="keep",enabled="y",
>> > addr="0x08048464",func="main",file="main.cpp",line="6",times="1"}]}
>> > 
>> > What is the point of producing spreadsheet-like output with columns and
>> > column heading and column alignment? I'd expect that any GUI frontend
>> > will have some specific representation and just ignore that extra
>> > formatting. Why generate it at all?
>> 
>> I agree, this output has always been useless to me. I would be happy to
>> see it go away.
> 
> I DON'T agree, and I think it would be a grave mistake to have this
> output go away.  About the worst thing a program can do is have some
> information and not reveal it.  Skipping unneeded information is easy;
> restoring missing one is next to impossible.

Well, let's see what would be missing. The number of rows is trivial to
restore. The number of columns -- well, given that the number of columns
given in above output is 6, while the actual number of fields is something
like 8, I'm not sure what "nr_cols" means at all.

Then, the column names. Any GUI can easily decide where to put each field
and how to name the corresponding GUI item given a list of possible field
names. I don't how it could be useful to know that gdb suggests to give
label "Enb" to the "enabled" field. 

Then, what's "alignment"? Does gdb has a command to set preferred alignment
for fields? If not, then alignment is just GDB's opinion about how GUI
behave, which is not likely to be correct. The width field is completely
redundant -- any GUI toolkit out there that can't auto-resize columns in a
table?

The extra information doesn't pertain to breakpoint itself, it's gdb opinion
on formatting and is hardly usefull for machine interface. IMO, of course.

- Volodya

Re: MI -break-info command issues

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Wed, 25 Jan 2006 14:11:47 +0300
> 
> >> I agree, this output has always been useless to me. I would be happy to
> >> see it go away.
> > 
> > I DON'T agree, and I think it would be a grave mistake to have this
> > output go away.  About the worst thing a program can do is have some
> > information and not reveal it.  Skipping unneeded information is easy;
> > restoring missing one is next to impossible.
> 
> Well, let's see what would be missing. The number of rows is trivial to
> restore. The number of columns -- well, given that the number of columns
> given in above output is 6, while the actual number of fields is something
> like 8, I'm not sure what "nr_cols" means at all.
> 
> Then, the column names. Any GUI can easily decide where to put each field
> and how to name the corresponding GUI item given a list of possible field
> names. I don't how it could be useful to know that gdb suggests to give
> label "Enb" to the "enabled" field. 
> 
> Then, what's "alignment"? Does gdb has a command to set preferred alignment
> for fields? If not, then alignment is just GDB's opinion about how GUI
> behave, which is not likely to be correct. The width field is completely
> redundant -- any GUI toolkit out there that can't auto-resize columns in a
> table?

All of your questions are explained in gdbint.texinfo, ui_out
functions are a piece of internals that _is_ documented, for a change.

> The extra information doesn't pertain to breakpoint itself, it's gdb opinion
> on formatting and is hardly usefull for machine interface. IMO, of course.

This output is produced by the UI-independent output functions.  So
judging its usefulness from the point of view of a GUI is taking a too
narrow view.  The advantage of ui_out routines is that whoever writes
the code defines the layout once, and then each UI gleans whatever it
needs from the results.  The programmer who wrote the code does not
need to bother which UI needs what information.  Yes, that means some
of the info will be redundant or useless for certain types of UI, but
that's by design, and I think the advantages of a single interface far
outweigh the small annoyances of having to read and discard unused
parts of the output.

Re: MI -break-info command issues

[Vladimir Prus]

Eli Zaretskii wrote:

>> The extra information doesn't pertain to breakpoint itself, it's gdb
>> opinion on formatting and is hardly usefull for machine interface. IMO,
>> of course.
> 
> This output is produced by the UI-independent output functions.  So
> judging its usefulness from the point of view of a GUI is taking a too
> narrow view.  The advantage of ui_out routines is that ....

I'm actually talking about MI *protocol*. I think that usefulness of that
should be judged from the point of view of its intended clients -- that are
frontends, which nowdays means GUI. If MI is protocol specifically designed
for some task, then it should not include some fields just because TUI
needs those fields.

> whoever writes 
> the code defines the layout once, and then each UI gleans whatever it
> needs from the results.  The programmer who wrote the code does not
> need to bother which UI needs what information.  Yes, that means some
> of the info will be redundant or useless for certain types of UI, but
> that's by design, and I think the advantages of a single interface far
> outweigh the small annoyances of having to read and discard unused
> parts of the output.

Why can't MI layer weed out unnecessary information?

- Volodya

Re: MI -break-info command issues

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Thu, 26 Jan 2006 10:01:43 +0300
> 
> Eli Zaretskii wrote:
> 
> >> The extra information doesn't pertain to breakpoint itself, it's gdb
> >> opinion on formatting and is hardly usefull for machine interface. IMO,
> >> of course.
> > 
> > This output is produced by the UI-independent output functions.  So
> > judging its usefulness from the point of view of a GUI is taking a too
> > narrow view.  The advantage of ui_out routines is that ....
> 
> I'm actually talking about MI *protocol*.

What ``protocol''?

> I think that usefulness of that
> should be judged from the point of view of its intended clients -- that are
> frontends, which nowdays means GUI. If MI is protocol specifically designed
> for some task, then it should not include some fields just because TUI
> needs those fields.

You may, of course, unilaterally decide that GDB/MI was (or should be)
meant for GUIs only, but that's not what it actually is about, as far
as GDB development is concerned.

> > whoever writes 
> > the code defines the layout once, and then each UI gleans whatever it
> > needs from the results.  The programmer who wrote the code does not
> > need to bother which UI needs what information.  Yes, that means some
> > of the info will be redundant or useless for certain types of UI, but
> > that's by design, and I think the advantages of a single interface far
> > outweigh the small annoyances of having to read and discard unused
> > parts of the output.
> 
> Why can't MI layer weed out unnecessary information?

And we are back to the beginning of this discussion, sigh...

Re: MI -break-info command issues

[Vladimir Prus]

On Thursday 26 January 2006 23:43, Eli Zaretskii wrote:
> > From:  Vladimir Prus <ghost@cs.msu.su>
> > Date:  Thu, 26 Jan 2006 10:01:43 +0300
> >
> > Eli Zaretskii wrote:
> > >> The extra information doesn't pertain to breakpoint itself, it's gdb
> > >> opinion on formatting and is hardly usefull for machine interface.
> > >> IMO, of course.
> > >
> > > This output is produced by the UI-independent output functions.  So
> > > judging its usefulness from the point of view of a GUI is taking a too
> > > narrow view.  The advantage of ui_out routines is that ....
> >
> > I'm actually talking about MI *protocol*.
>
> What ``protocol''?

Let's replace "protocol" with "formal interface". I was told here that all 
frontends should use MI, because unlike console output, it's a formal 
interface. And I'd expect that "formal" means "designed in detail for 
specific task". That's why I don't understand the reasoning that MI response 
contains certain field just because some internal code works that way. That's 
backward -- if MI is to be formal interface, then MI spec should drive the 
code, not the other way around.

> > I think that usefulness of that
> > should be judged from the point of view of its intended clients -- that
> > are frontends, which nowdays means GUI. If MI is protocol specifically
> > designed for some task, then it should not include some fields just
> > because TUI needs those fields.
>
> You may, of course, unilaterally decide that GDB/MI was (or should be)
> meant for GUIs only, but that's not what it actually is about, as far
> as GDB development is concerned.

Can you name frontend that uses MI and that is not GUI, just as example.

> > > whoever writes
> > > the code defines the layout once, and then each UI gleans whatever it
> > > needs from the results.  The programmer who wrote the code does not
> > > need to bother which UI needs what information.  Yes, that means some
> > > of the info will be redundant or useless for certain types of UI, but
> > > that's by design, and I think the advantages of a single interface far
> > > outweigh the small annoyances of having to read and discard unused
> > > parts of the output.
> >
> > Why can't MI layer weed out unnecessary information?
>
> And we are back to the beginning of this discussion, sigh...

Ok, let's consider another command which does not share any implementation 
with console output: -data-read-memory, implemented entirely in mi-main.c.
The output from that command is:

      (gdb)5-data-read-memory shorts+64 d 2 1 1
      5^done,addr="0x00001510",nr-bytes="2",total-bytes="2",
      next-row="0x00001512",prev-row="0x0000150e",
      next-page="0x00001512",prev-page="0x0000150e",memory=[
      {addr="0x00001510",data=["128"]}]
      (gdb)

It includes fields like "next-page", which IMO, are not sufficiently 
documented. At the same time, the code to compute that field is this:

     ui_out_field_core_addr (uiout, "next-page", addr + total_bytes);

What is the point for machine interface to have a field that is not documented 
and that can be trivially computed by the frontend if needed? If you had the 
luxury to design MI from the start, would you include this field?

- Volodya

Re: MI -break-info command issues

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 27 Jan 2006 11:15:22 +0300
> Cc: gdb@sources.redhat.com
> 
> Let's replace "protocol" with "formal interface". I was told here that all 
> frontends should use MI, because unlike console output, it's a formal 
> interface.

I'm not sure that's the main reason.  AFAIK, the main reason is that
MI was _designed_ to be easily understandable by programs (thus the
`M' in "MI"), in contrast to annotations, which are after-thought
ad-hoc additions to the CLI interface, which was originally designed
for interaction with _humans_.

> And I'd expect that "formal" means "designed in detail for specific
> task".

That's the theory, yes.

> That's why I don't understand the reasoning that MI response 
> contains certain field just because some internal code works that way. That's 
> backward -- if MI is to be formal interface, then MI spec should drive the 
> code, not the other way around.

I didn't say that MI includes something just because the code ``works
that way''.  It includes those specific fields because some UI might
need them.

> Can you name frontend that uses MI and that is not GUI, just as example.

Why should I bother?  MI is a general-purpose interface, it's not
limited to GUI.  That's its design goal.  Even if there's no UI at
this time that uses MI, it doesn't necessarily mean we should forever
ban such UIs from coming into existence, just because there are a few
fields a GUI normally won't want.

But if you insist, here's one example: Emacs's gdb-ui when Emacs runs
on a text-mode display (e.g., when one logs into a remote machine
through a telnet client).  Yes, Emacs currently doesn't use MI, but
AFAIR that's Nick's long-term goal, and there's even a development
version of the interface that uses MI.

But again, I don't think examples are important to this discussion.
If you are willing to lobby us to drop text-mode front-end support in
GDB/MI, then it's okay to discuss that, but I personally would then
ask to come up with arguments against such support that are much more
grave than just a few gratuitous fields.  Dropping an existing
feature, in general, needs a very good reason, because of the risk
that we hurt some potential users somewhere.  All unused fields do is
make the interface more voluminous.  Someone actually suggested to
replace MI with XML a few months ago, so evidently at least that
person didn't think the current interface is too wordy.

> > > Why can't MI layer weed out unnecessary information?
> >
> > And we are back to the beginning of this discussion, sigh...
> 
> Ok, let's consider another command which does not share any implementation 
> with console output: -data-read-memory, implemented entirely in mi-main.c.

I'm not sure where you are taking this discussion; can you please
spell that out?  Are you saying that MI's design is faulty? or perhaps
that implementation of certain commands Needs Work(tm)? or that the
documentation is not clear or detailed enough? or something else
entirely?

> The output from that command is:
> 
>       (gdb)5-data-read-memory shorts+64 d 2 1 1
>       5^done,addr="0x00001510",nr-bytes="2",total-bytes="2",
>       next-row="0x00001512",prev-row="0x0000150e",
>       next-page="0x00001512",prev-page="0x0000150e",memory=[
>       {addr="0x00001510",data=["128"]}]
>       (gdb)
> 
> It includes fields like "next-page", which IMO, are not sufficiently 
> documented.

I see in the manual that next-page is documented thusly:

    The address of the next/previous row or page is available in
    `next-row' and `prev-row', `next-page' and `prev-page'.

Now, if you are saying that this is unclear, I will happily try to
make it better.  How about this replacement text:

    The first memory address to be displayed on the next/previous
    row or page is given as the values of the fields `next-row' and
    `prev-row', `next-page' and `prev-page', respectively.

> At the same time, the code to compute that field is this:
> 
>      ui_out_field_core_addr (uiout, "next-page", addr + total_bytes);
> 
> What is the point for machine interface to have a field that is not documented 

But it _is_ documented.

> and that can be trivially computed by the frontend if needed?

This is trivial only when you look at how the values are computed.
One reason why it might be useful for GDB/MI to return these values is
that a UI programmer shouldn't have to look into the GDB sources to
understand how to display the data.

But that's a guess; I'm not one of the designers of MI.  Perhaps
someone else could give a more definitive answer to your question.

> If you had the luxury to design MI from the start, would you include
> this field?

I don't know, and I don't have that luxury anyway.

Re: MI -break-info command issues

[Bob Rossi]

On Fri, Jan 27, 2006 at 02:15:41PM +0200, Eli Zaretskii wrote:
> > Can you name frontend that uses MI and that is not GUI, just as example.
> 
> Why should I bother?  MI is a general-purpose interface, it's not
> limited to GUI.  That's its design goal.  Even if there's no UI at
> this time that uses MI, it doesn't necessarily mean we should forever
> ban such UIs from coming into existence, just because there are a few
> fields a GUI normally won't want.

I agree that the data is useless. However, Eli's concern is that it
might not be useless to a particular program that is already using it.

If we remove it, I'm sure the developer (of the program that uses the
data) wouldn't be happy. Does it really hurt to leave it there? 
I will just ignore it.

However, I do have an opinion that new commands should not contain
formatting data like this. It's pushing mechanism over policy.
  http://www.faqs.org/docs/artu/ch01s06.html#id2877777

Bob Rossi

Re: MI -break-info command issues

[Vladimir Prus]

Eli Zaretskii wrote:

>> The output from that command is:
>> 
>>       (gdb)5-data-read-memory shorts+64 d 2 1 1
>>       5^done,addr="0x00001510",nr-bytes="2",total-bytes="2",
>>       next-row="0x00001512",prev-row="0x0000150e",
>>       next-page="0x00001512",prev-page="0x0000150e",memory=[
>>       {addr="0x00001510",data=["128"]}]
>>       (gdb)
>> 
>> It includes fields like "next-page", which IMO, are not sufficiently
>> documented.
> 
> I see in the manual that next-page is documented thusly:
> 
>     The address of the next/previous row or page is available in
>     `next-row' and `prev-row', `next-page' and `prev-page'.

Yes, and the only extra information this paragraph adds to the names of
fields is that the value of those fields are addresses. Otherwise it
repeats the name of fields in more verbose english.

> Now, if you are saying that this is unclear, I will happily try to
> make it better.  How about this replacement text:
> 
>     The first memory address to be displayed on the next/previous
>     row or page is given as the values of the fields `next-row' and
>     `prev-row', `next-page' and `prev-page', respectively.

This misses the definition of 'page' and definition of 'next'/'prev'. Based
on looking on the code, I could suggest this:

   Assuming memory is a sequence of "pages", where each "page" is "total-nr"
   bytes the "next-page" is the address of page directly after the page
   returned by -data-read-memory, and "prev-page" is the address of the
   first byte of the directly preceding page. Likewise, assuming memory
   is a sequence of rows, where each row is word_size*nr_cols bytes,
   "next-row" is the address of the row directly after the first one in
   the -data-read-memory output (that is, the address of the second row of
   the output, if there's second row). The "prev-row" is the start address
   of the row directly preceding the first output row.

Another variant:
        
   The 'next-page' field gives the address of the memory immediately
   following the memory returned by the command. The 'prev-page' gives the
   memory address that's 'total-bytes' before the starting address of
   the memory region returned by the command. .....


>> and that can be trivially computed by the frontend if needed?
> 
> This is trivial only when you look at how the values are computed.
> One reason why it might be useful for GDB/MI to return these values is
> that a UI programmer shouldn't have to look into the GDB sources to
> understand how to display the data.

That's only valid if it's easier for UI programmer to understand how those
fields are to be used, than to write the simular pointer code. The second
variant of docs I suggested basically documents address manupulation gdb
will do, it's not conceptually better then doing the manupulation itself.
The first variant of docs introduces the concept of "page" which can be
confusing it itself.

>> Ok, let's consider another command which does not share any
>> implementation with console output: -data-read-memory, implemented
>> entirely in mi-main.c.
> 
> I'm not sure where you are taking this discussion; can you please
> spell that out?  Are you saying that MI's design is faulty? or perhaps
> that implementation of certain commands Needs Work(tm)? or that the
> documentation is not clear or detailed enough? or something else
> entirely?

That's a good question. The general design of MI is good, and extracting
information from MI replies is much easier then from console output. But
there are some issues:

1. Some commands produce fields that appear to be unnecessary. The
documentation does not say why they are useful. For example table heading
for -break-list, prev/next for -data-read-memory. I also recall a related
issue: http://sources.redhat.com/ml/gdb/2005-07/msg00164.html
where again gdb outputs information that not all frontends need (and which
KDevelop has to explicitly eliminate, which is not that simple).

2. The documentation is incomplete. All MI commands are documented with
examples. It's not clear if all shown fields in replies will always be
output, or if not, in what combinations. 

3. It's not sufficiently clear what commands are implemented, and what are
not. Consider -break-info that's marked with "N.A" but still implemented.

4. There's too little rationale. Why "variable-objects" are better
interface? It's not stated anywhere, so how I can use them efficiently?

This leaves very simple approach for porting to MI: pick a command that
looks suitable, then look at the output, and pick used the parts that look
suitable. It might even work. But I think a machine protocol must be
minimal and documented (if minimal protocol is easier to document). 

If "minimal" protocol is explicitly not a goal of MI, or changing MI is
prohibited, just say so and I'll stop asking why there are unnecessary
fields.

- Volodya

Re: MI -break-info command issues

[Daniel Jacobowitz]

On Fri, Jan 27, 2006 at 05:59:56PM +0300, Vladimir Prus wrote:
> If "minimal" protocol is explicitly not a goal of MI, or changing MI is
> prohibited, just say so and I'll stop asking why there are unnecessary
> fields.

_Extending_ MI is fine; it was designed to be extensible.  _Removing_
fields from MI is not fine, because you don't know if some other
frontend relies on the data that you find superfluous.

Folks have said this at least twice in this thread already.  If you
disagree, could you say why?

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI -break-info command issues

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Fri, Jan 27, 2006 at 05:59:56PM +0300, Vladimir Prus wrote:
>> If "minimal" protocol is explicitly not a goal of MI, or changing MI is
>> prohibited, just say so and I'll stop asking why there are unnecessary
>> fields.
> 
> _Extending_ MI is fine; it was designed to be extensible.  _Removing_
> fields from MI is not fine, because you don't know if some other
> frontend relies on the data that you find superfluous.
> 
> Folks have said this at least twice in this thread already.  If you
> disagree, could you say why?

Because with those fields, you get new issues:

1. They are not documented in sufficient detail.
2. Looking at 'mi-read-memory.exp', those fields don't appear to be tested
-- it's only checked that the values of the fields are in hex.
3. Everybody using MI should decide if those fields are useful for him, or
not.

The problem with existing frontends can probably be solved by posting a
prominent message to mailing list whenever MI output is going to change. Or
using versioning.

- Volodya

Re: MI -break-info command issues

[Daniel Jacobowitz]

On Fri, Jan 27, 2006 at 06:47:47PM +0300, Vladimir Prus wrote:
> > On Fri, Jan 27, 2006 at 05:59:56PM +0300, Vladimir Prus wrote:
> >> If "minimal" protocol is explicitly not a goal of MI, or changing MI is
> >> prohibited, just say so and I'll stop asking why there are unnecessary
> >> fields.
> > 
> > _Extending_ MI is fine; it was designed to be extensible.  _Removing_
> > fields from MI is not fine, because you don't know if some other
> > frontend relies on the data that you find superfluous.
> > 
> > Folks have said this at least twice in this thread already.  If you
> > disagree, could you say why?
> 
> Because with those fields, you get new issues:
> 
> 1. They are not documented in sufficient detail.
> 2. Looking at 'mi-read-memory.exp', those fields don't appear to be tested
> -- it's only checked that the values of the fields are in hex.
> 3. Everybody using MI should decide if those fields are useful for him, or
> not.

I don't buy it.  If you don't know for sure what they do, and you don't
need them, just ignore them - MI is designed to make unknown fields
easy to ignore.

> The problem with existing frontends can probably be solved by posting a
> prominent message to mailing list whenever MI output is going to change. Or
> using versioning.

This has been discussed before plenty of times.  We will make
incompatible changes to MI from time to time; but IMO that doesn't
justify making _unnecessary_ incompatible changes.

Like Bob, I wouldn't have added the fields.  But since they are
present, I see no reason to remove them.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI -break-info command issues

[Daniel Jacobowitz]

On Fri, Jan 27, 2006 at 06:47:47PM +0300, Vladimir Prus wrote:
> > On Fri, Jan 27, 2006 at 05:59:56PM +0300, Vladimir Prus wrote:
> >> If "minimal" protocol is explicitly not a goal of MI, or changing MI is
> >> prohibited, just say so and I'll stop asking why there are unnecessary
> >> fields.
> > 
> > _Extending_ MI is fine; it was designed to be extensible.  _Removing_
> > fields from MI is not fine, because you don't know if some other
> > frontend relies on the data that you find superfluous.
> > 
> > Folks have said this at least twice in this thread already.  If you
> > disagree, could you say why?
> 
> Because with those fields, you get new issues:
> 
> 1. They are not documented in sufficient detail.
> 2. Looking at 'mi-read-memory.exp', those fields don't appear to be tested
> -- it's only checked that the values of the fields are in hex.
> 3. Everybody using MI should decide if those fields are useful for him, or
> not.

I don't buy it.  If you don't know for sure what they do, and you don't
need them, just ignore them - MI is designed to make unknown fields
easy to ignore.

> The problem with existing frontends can probably be solved by posting a
> prominent message to mailing list whenever MI output is going to change. Or
> using versioning.

This has been discussed before plenty of times.  We will make
incompatible changes to MI from time to time; but IMO that doesn't
justify making _unnecessary_ incompatible changes.

Like Bob, I wouldn't have added the fields.  But since they are
present, I see no reason to remove them.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI -break-info command issues

[Vladimir Prus]

Daniel Jacobowitz wrote:

>> The problem with existing frontends can probably be solved by posting a
>> prominent message to mailing list whenever MI output is going to change.
>> Or using versioning.
> 
> This has been discussed before plenty of times.  We will make
> incompatible changes to MI from time to time; but IMO that doesn't
> justify making _unnecessary_ incompatible changes.
> 
> Like Bob, I wouldn't have added the fields.  But since they are
> present, I see no reason to remove them.

Ok, understood. It would be good, though, if MI docs contained some
introduction chapter that would state this policy. That'd prevented this
thread from ever starting.

- Volodya


 

Re: MI -break-info command issues

[Bob Rossi]

On Fri, Jan 27, 2006 at 07:09:56PM +0300, Vladimir Prus wrote:
> Daniel Jacobowitz wrote:
> 
> >> The problem with existing frontends can probably be solved by posting a
> >> prominent message to mailing list whenever MI output is going to change.
> >> Or using versioning.
> > 
> > This has been discussed before plenty of times.  We will make
> > incompatible changes to MI from time to time; but IMO that doesn't
> > justify making _unnecessary_ incompatible changes.
> > 
> > Like Bob, I wouldn't have added the fields.  But since they are
> > present, I see no reason to remove them.
> 
> Ok, understood. It would be good, though, if MI docs contained some
> introduction chapter that would state this policy. That'd prevented this
> thread from ever starting.

Hi Volodya,

It would be great if you could come up with some text that described the
problem. We could improve it here, and then add it to the manual.

Bob Rossi

Documenting MI stability (Was: MI -break-info command issues)

[Vladimir Prus]

On Friday 27 January 2006 19:13, Bob Rossi wrote:
> On Fri, Jan 27, 2006 at 07:09:56PM +0300, Vladimir Prus wrote:
> > Daniel Jacobowitz wrote:
> > >> The problem with existing frontends can probably be solved by posting
> > >> a prominent message to mailing list whenever MI output is going to
> > >> change. Or using versioning.
> > >
> > > This has been discussed before plenty of times.  We will make
> > > incompatible changes to MI from time to time; but IMO that doesn't
> > > justify making _unnecessary_ incompatible changes.
> > >
> > > Like Bob, I wouldn't have added the fields.  But since they are
> > > present, I see no reason to remove them.
> >
> > Ok, understood. It would be good, though, if MI docs contained some
> > introduction chapter that would state this policy. That'd prevented this
> > thread from ever starting.
>
> Hi Volodya,
>
> It would be great if you could come up with some text that described the
> problem. We could improve it here, and then add it to the manual.

Hi Bob,

What about this:

    = Stability =

    While MI format is still evoling, all changes to it will be backward
    compatible. That is, only new fields will be added, and all existing
    fields will be retained. 

    This means that replies to certain command might contain information that
    is not strictly necessary for machine interface, and a present for
    historical reasons only.

    Rationale: There are many MI frontends around, and their developers don't
    necessary follow MI changes and read the mailing list, so it's better
    to live with a few extra fields than risk breaking existing code.

You probably can phrase this better, but something to this effect will be a 
good addition to MI manual. And it would be great to have some guidelines 
when MI compatibility *can* be broken -- I don't know those guidelines so 
can't write anything about it.

Thanks,
Volodya

Re: MI -break-info command issues

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Fri, 27 Jan 2006 19:09:56 +0300
> 
> It would be good, though, if MI docs contained some introduction
> chapter that would state this policy.

I agree, and will gladly accept patches to this effect.

Re: MI -break-info command issues

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Fri, 27 Jan 2006 18:47:47 +0300
> 
> > _Extending_ MI is fine; it was designed to be extensible.  _Removing_
> > fields from MI is not fine, because you don't know if some other
> > frontend relies on the data that you find superfluous.
> > 
> > Folks have said this at least twice in this thread already.  If you
> > disagree, could you say why?
> 
> Because with those fields, you get new issues:
> 
> 1. They are not documented in sufficient detail.

The truth is, _nothing_ in GDB/MI is documented in sufficient detail.
We are lucky to have any documentation at all.

Historically, GDB/MI was added to the sources without _any_
documentation.  I needed to lobby those who wrote the code to make
some docs available, and finally got a kind of white paper that
described what MI _will_ look like; it goes without saying that the
reality was quite different.  I then needed to edit that document
heavily to make it fit into the manual (convert chapters to sections,
sections to subsections, fix style and Texinfo usage, etc.) and that
is what we have now, basically, except that some portions were
improved since then, whenever commands were added/changed.

I will personally applaud anyone who submits improvements to the MI
docs.

> 2. Looking at 'mi-read-memory.exp', those fields don't appear to be tested
> -- it's only checked that the values of the fields are in hex.

I'm sure we will happily accept patches to the test suite as well.

> 3. Everybody using MI should decide if those fields are useful for him, or
> not.

If you have ideas how to improve this aspect (without hurting
generality), please consider sharing them.

> The problem with existing frontends can probably be solved by posting a
> prominent message to mailing list whenever MI output is going to change. Or
> using versioning.

The latter possibility was discussed in some length several months
ago, and I think we have now a mechanism to do this.

Re: MI -break-info command issues

[Bob Rossi]

On Fri, Jan 27, 2006 at 07:10:54PM +0200, Eli Zaretskii wrote:
> > From:  Vladimir Prus <ghost@cs.msu.su>
> > Date:  Fri, 27 Jan 2006 18:47:47 +0300
> > 
> > > _Extending_ MI is fine; it was designed to be extensible.  _Removing_
> > > fields from MI is not fine, because you don't know if some other
> > > frontend relies on the data that you find superfluous.
> > > 
> > > Folks have said this at least twice in this thread already.  If you
> > > disagree, could you say why?
> > 
> > Because with those fields, you get new issues:
> > 
> > 1. They are not documented in sufficient detail.
> 
> The truth is, _nothing_ in GDB/MI is documented in sufficient detail.
> We are lucky to have any documentation at all.
> 
> Historically, GDB/MI was added to the sources without _any_
> documentation.  I needed to lobby those who wrote the code to make
> some docs available, and finally got a kind of white paper that
> described what MI _will_ look like; it goes without saying that the
> reality was quite different.  I then needed to edit that document
> heavily to make it fit into the manual (convert chapters to sections,
> sections to subsections, fix style and Texinfo usage, etc.) and that
> is what we have now, basically, except that some portions were
> improved since then, whenever commands were added/changed.

Eli, one thought I had recently was this. I would like to automate the
examples, using the testsuite. So that if an MI output command changed,
the sample would be updated. Do you think this would be possible to do?

I find the documentation get's quickly out of date with what GDB is
actually outputting. We could add a new test case, which would get the
mi output commands we are interested in, and put them in the tex file
somehow. What do you think? Sounds ambitious, I know.

Bob Rossi

Re: MI -break-info command issues

[Eli Zaretskii]

> Date: Fri, 27 Jan 2006 12:17:17 -0500
> From: Bob Rossi <bob@brasko.net>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> > Historically, GDB/MI was added to the sources without _any_
> > documentation.  I needed to lobby those who wrote the code to make
> > some docs available, and finally got a kind of white paper that
> > described what MI _will_ look like; it goes without saying that the
> > reality was quite different.  I then needed to edit that document
> > heavily to make it fit into the manual (convert chapters to sections,
> > sections to subsections, fix style and Texinfo usage, etc.) and that
> > is what we have now, basically, except that some portions were
> > improved since then, whenever commands were added/changed.
> 
> Eli, one thought I had recently was this. I would like to automate the
> examples, using the testsuite. So that if an MI output command changed,
> the sample would be updated. Do you think this would be possible to do?

I don't like the idea of asking people to install dejagnu+expect just
to produce the docs.

Perhaps we could instead come up with some way of running each of the
MI commands through "gdb -i mi", and capturing the output to produce
the examples for the manual.  If you wish to work on this, I'd support
such a change.  It would involve extracting the MI commands from the
manual, running GDB, capturing the output, and inserting it into the
examples.

Re: MI -break-info command issues

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Fri, 27 Jan 2006 17:59:56 +0300
> 
> >     The first memory address to be displayed on the next/previous
> >     row or page is given as the values of the fields `next-row' and
> >     `prev-row', `next-page' and `prev-page', respectively.
> 
> This misses the definition of 'page' and definition of 'next'/'prev'. Based
> on looking on the code, I could suggest this:
> 
>    Assuming memory is a sequence of "pages", where each "page" is "total-nr"
>    bytes the "next-page" is the address of page directly after the page
>    returned by -data-read-memory, and "prev-page" is the address of the
>    first byte of the directly preceding page. Likewise, assuming memory
>    is a sequence of rows, where each row is word_size*nr_cols bytes,
>    "next-row" is the address of the row directly after the first one in
>    the -data-read-memory output (that is, the address of the second row of
>    the output, if there's second row). The "prev-row" is the start address
>    of the row directly preceding the first output row.

Thanks, but this is too wordy.  I will try to come up with some
suitable definition of `page'.  (I don;t think that `previous' needs a
definition; perhaps you meant that `previous page' needs it.)

> 1. Some commands produce fields that appear to be unnecessary. The
> documentation does not say why they are useful. For example table heading
> for -break-list, prev/next for -data-read-memory. I also recall a related
> issue: http://sources.redhat.com/ml/gdb/2005-07/msg00164.html
> where again gdb outputs information that not all frontends need (and which
> KDevelop has to explicitly eliminate, which is not that simple).
> 
> 2. The documentation is incomplete. All MI commands are documented with
> examples. It's not clear if all shown fields in replies will always be
> output, or if not, in what combinations. 
> 
> 3. It's not sufficiently clear what commands are implemented, and what are
> not. Consider -break-info that's marked with "N.A" but still implemented.
> 
> 4. There's too little rationale. Why "variable-objects" are better
> interface? It's not stated anywhere, so how I can use them efficiently?

All good points, IMHO.  Patches are welcome to fix them.

> If "minimal" protocol is explicitly not a goal of MI, or changing MI is
> prohibited, just say so and I'll stop asking why there are unnecessary
> fields.

It's not prohibited.  And if superfluous fields are a big annoyance,
how about an MI command that would remove them?  Would you like to
submit a patch along these lines?

-data-read-memory docs (Was: MI -break-info command issues)

[Vladimir Prus]

On Friday 27 January 2006 20:00, Eli Zaretskii wrote:
> > From:  Vladimir Prus <ghost@cs.msu.su>
> > Date:  Fri, 27 Jan 2006 17:59:56 +0300
> >
> > >     The first memory address to be displayed on the next/previous
> > >     row or page is given as the values of the fields `next-row' and
> > >     `prev-row', `next-page' and `prev-page', respectively.
> >
> > This misses the definition of 'page' and definition of 'next'/'prev'.
> > Based on looking on the code, I could suggest this:
> >
> >    Assuming memory is a sequence of "pages", where each "page" is
> > "total-nr" bytes the "next-page" is the address of page directly after
> > the page returned by -data-read-memory, and "prev-page" is the address of
> > the first byte of the directly preceding page. Likewise, assuming memory
> > is a sequence of rows, where each row is word_size*nr_cols bytes,
> > "next-row" is the address of the row directly after the first one in the
> > -data-read-memory output (that is, the address of the second row of the
> > output, if there's second row). The "prev-row" is the start address of
> > the row directly preceding the first output row.
>
> Thanks, but this is too wordy.  I will try to come up with some
> suitable definition of `page'.  (I don;t think that `previous' needs a
> definition; perhaps you meant that `previous page' needs it.)

Eli,
have you had a chance to think about a better documentation for this?

Thanks,
Volodya

Re: -data-read-memory docs (Was: MI -break-info command issues)

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 17 Mar 2006 20:06:19 +0300
> Cc: gdb@sources.redhat.com
> 
> Eli,
> have you had a chance to think about a better documentation for this?

Not yet, sorry.