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