Re: MI rules

Bob Rossi
2004-09-29T17:27:57Z

Hi Jim,

Thanks again for taking the time to discuss this with me.

On Wed, Sep 29, 2004 at 09:13:41AM -0700, Jim Ingham wrote:
> Bob,
>
> First, I think parts of the discussion are unclear because you are a
> little lax on terminology. What you are calling asynchronous COMMANDS
> are really asynchronous NOTIFICATIONS. They aren't the result of a
> command, but something that happens in gdb that gdb decides it ought to
> tell you about. There are actually different mechanisms to emit them
> in gdb, so they are clearly separated in the code.

OK, understood that there is some miscommunication. I refer to all
output commands as MI output commands, if they are asyncronous or not. I
picked this terminology up from the manual at 24.1.2 GDB/MI Output Syntax.

The async-record is in particular what I mean when I say asyncronous and
it is part of an MI output command. I believe that at least these
asyncronous MI output commands need to have a tag in order for the front
end to undestand what kind of MI output command ( asyncronous
notification ) is being sent from GDB.

> And yes, ALL asynchronous notifications need to be tagged. I haven't
> played around with TOT without our modifications, so I can't actually
> tell you what the state is there, but if this isn't the case it
> certainly ought to be. I would be surprised if they weren't, but...

The tag is not in the grammer. So, if it is actually outputted by GDB
then I would be very happy because just the grammer needs to be updated.
However, if it the grammer is correct, I need this in the mainline GDB
to get some reasonable work done. I would be happy to work on the
implemenation, unless of course you already have a patch that does just
what I need.

> About incompatible changes. I see the need to have a stable version of
> the MI so that you can deliver a front end that will work with some
> reasonable range of gdb's. OTOH, putting a whole lot of effort into
> making your front end work with every possible variant of the
> development versions of the MI seems to me like a misdirection of our
> limited resources. The current state falls short of your needs right
> now because you need to use the development version only, and until
> that is stable, you are in a bind. But over designing for a side
> effect of the software not being all the way done is not as good a use
> of resources as actually getting a stable version that has what you
> need...

I understand what you are saying. Unfortunatly the reality is that many
major distributions ( debian ) take a snapshot of GDB, instead of
waiting for a major release. Because of this, front ends would not work
out of the box on normal distributions. This seems unreasonable.

> The thing I think we really need to work on (besides tagging
> notifications if there is any place they aren't tagged) is making the
> command INPUT more robust. The output is already pretty good, there is
> seldom a need to remove fields, and adding fields is done in a way that
> the client can handle. But the command input is not similarly
> self-labeling, and thus much more fragile.

I am very willing to work on the MI input commands. I'm sure I'll be
making a lot of noise when I get to that point. However, I haven't
even gotten to that point because I am trying to design and implement
the parsing of the MI output commands. Until I can get that working
properly, I can't even think about the input commands.

>
> Jim
>
> On Sep 28, 2004, at 7:59 PM, Bob Rossi wrote:
>
> >I have one quick note. I would prefer to get some cooperation with the
> >MI maintainers. I seriously need this cooperation in order to get
> >anything done with CGDB. Also, I consider the work I am doing necessary
> >for any front end developer to be able to write a reasonable front end
> >without having to heavily patch a version of GDB they distribute with.
> >
> >If you consider my goal worthy, please at least respond with some
> >reasonable criticism so that these issues can be resolved. I feel that
> >in
> >many ways my views on the MI are mostly ignored by the MI maintainers.
> >I would like to improve GDB in the areas that seem relevant to front
> >end
> >developers and am assuming that you all have the same goal. So
> >hopefully these issues and the ones in the future can be resolved
> >within
> >a reasonable amount of time.
> >
> >
> >On Mon, Sep 27, 2004 at 10:38:55AM -0700, Jim Ingham wrote:
> >>
> >>On Sep 25, 2004, at 1:12 PM, Bob Rossi wrote:
> >>
> >>>On Sat, Sep 25, 2004 at 12:01:28PM -0700, Jim Ingham wrote:
> >>>>I have no strong opposition to this, I just don't see the point.
> >>>>
> >>>
> >>>Jim, I appreciate the time you have spent thinking about this issue
> >>>for
> >>>me. I value the input from someone who has been working with MI for
> >>>quite some time. I have several questions for you,
> >>>
> >>> 1. How do you figure out what type of asynchronous MI output
> >>>command
> >>> you just received is?
> >>
> >>There are two things here - there is asynchronous output from an MI
> >>command, like stopped, running, etc. We added "running breakpoint
> >>command message so you can tell that it might start up again..." This
> >>sort of thing - usually from running. They are always linked to the
> >>original command by preserving the command token. So that's easy.
> >>
> >>Then there is true asynchronous communications from the inferior -
> >>unsolicited messages like shared library notification, or the fact
> >>that
> >>a user command ("interpreter-exec") caused a breakpoint to be set, the
> >>thread or the frame to be changed, etc... These are all dealt with
> >>just as you suggest for commands - they have a tag at the beginning
> >>specifying the kind of event. So for instance, when a shared library
> >>gets loaded, we get:
> >>
> >>=shlibs-added,shlib-info=
> >>[num="6",name="PBGDBIntrospectionSupport.A.dylib",kind="-",dyld-
> >>addr="0x83d50000",reason="dyld",requested-
> >>state="?",state="N",path="",description="/Developer/Applications/
> >>Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin/Contents/Resources/
> >>PBGDBIntrospectionSupport.A.dylib",slide="",addr="",prefix=""]
> >
> >OK, so this is exactly what I'm talking about. There needs to be a
> >label
> >for asynchronous commands. I guess it's not necessary for synchronous
> >commands but I think it could be useful to have there anyways and it
> >would be trivial to add.
> >
> >>Again, the truely unsolicited stuff (in this case the breakpoint
> >>creation notification) is all tagged so the UI can figure out what is
> >>going on.
> >
> >I think this also needs to be done in the mainline GDB and I would
> >prefer the synchronous commands to get a tag also. Do you agree with
> >the
> >asynchronous part at least?
> >
> >>> 2. How do you deal with your MI front end dealing with snapshots of
> >>> GDB? For example, it has new asynchronous commands, but the MI
> >>>version
> >>> hasn't been bumped yet.
> >>
> >>There are two kinds of additions, right? Command return fields, and
> >>async notifications. In Xcode,
> >>the parser parses everything, and then any command return fields or
> >>async notifications that it doesn't understand, it ignores. That's
> >>pretty much how the MI was designed, so that the MI can freely ADD
> >>notifications & command return fields, and the UI can just ignore
> >>them.
> >> The fields are identified by field name, and the notifications by
> >>their notification name.
> >
> >OK, so understood.
> >
> >Commands that add a field will definatly work because the front end
> >ignores them. Commands that loose a field will probably cause a major
> >problem and will be incompatible with the front end.
> >
> >What about when a command changes completly because of a version bump?
> >What about when the commands changes (like N:M breakpoints) and the
> >version is not bumped yet because you have a snapshot of GDB?
> >
> >I need these case's to work because I am not bundled with GDB.
> >
> >So again, I'm asking everyone,
> >
> >1. Can the mainline version get tagged asyncronous commands at the
> >least?
> >I would prefer every command to have a tag.
> >
> >2. Can there be a discussion about backwards compatibility with MI
> >output commands. This involves several issues I can think of.
> > 1. removing fields from an MI output command
> > 2. changing the output of an MI output command
> > 3. Making the commands themselves be backwards compatible even
> > between major releases. This essentially makes the MI output version
> > useless.
> >
> >Thanks,
> >Bob Rossi
> >
> --
> Jim Ingham jingham@apple.com
> Developer Tools
> Apple Computer