This is the mail archive of the gdb@sources.redhat.com 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 rules


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


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