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


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

Re: MI -break-info command issues


> 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.


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