* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 [not found] <1035593825.16489.ezmlm@sources.redhat.com> @ 2002-10-25 18:22 ` Jim Ingham 0 siblings, 0 replies; 29+ messages in thread From: Jim Ingham @ 2002-10-25 18:22 UTC (permalink / raw) To: gdb-patches Andrew, On Friday, October 25, 2002, at 05:57 PM, gdb-patches-digest-help@sources.redhat.com wrote: > From: Andrew Cagney <ac131313@redhat.com> > Date: Fri Oct 25, 2002 2:48:09 PM US/Pacific > To: Jim Ingham <jingham@apple.com> > Cc: Keith Seitz <keiths@redhat.com>, gdb-patches@sources.redhat.com > Subject: > > > [Did anyone mention that Apple's mail tool is officially weird?] > [was a good holiday] > > >>> On Wednesday, October 2, 2002, at 08:01 AM, Keith Seitz wrote: >>>> On Tue, 1 Oct 2002, Jim Ingham wrote: >>>> I don't want a tight coupling in TIME, or in the output sequence. I >>>> want meta-info which tells me with 100% certainty that this result >>>> is >>>> the result of command foo, that I sent some time in the past, >>>> precisely >>>> so I DON'T have to rely on anything about the sequencing of input or >>>> output to make this connection. >>> Ok, but this is exactly what I don't understand: what does it matter >>> where >>> the breakpoint comes from? All that matters is that you have issued a >>> command, and you don't do anything out of the normaluntil an event >>> from >>> GDB telling you that it has set a breakpoint. You just sit in your >>> event >>> loop waiting for any event (GUI, paint, GDB, blah blah blah). > >> In large part, it is just that if I can track cause & effect >> unambiguously, everything is much cleaner. From PB, I issue a >> command, I want to tick off when that command succeeded, and gather >> all the data from the result I need. If I get a note back from gdb >> saying, "The third command down in the command stream that you >> issued, here is the result to it." then I can do this without any >> effort. However, in your proposed implementation, I have to peer at >> the command stream and wait both for an anonymous breakpoint created >> message, and a for the done message (to know things are formally >> done, and because it would be very dangerous to just toss aside bits >> of the output stream, since it reduces your chances of catching & >> handling errors intelligently.) Then I have to use some smarts to >> tie the breakpoint created message to the particular message I sent >> to gdb. This is harder to do, and fragile. > >> In my mind, one of the major advantages of the MI was that it made >> this tie between the command you sent and the result that came from >> it explicit and unambiguous. This was in response to a lot of the >> pain that we suffered in insight where any random spew from the >> command line would get itself inserted into the "results" of the >> command you thought you were executing. You are breaking this tie by >> moving the results of a command from the command result to an >> untagged asynchronous event. For breakpoints, this is probably just >> an inconvenience. But if we follow this as a principle, then in more >> complex cases, where it is not so easy to tell whether an >> asynchronous notification arose from a command initiated by the MI, >> or from some other action we will likely start getting confused >> again. For instance, we might have something happening in the >> target, or some console command, or something more gnarly like the >> results of a breakpoint command which also continued the target while >> you thought it was just running... > > You mean like > http://sources.redhat.com/gdb/papers/libgdb2/wp/gdbtk2.jpg > Cute... > There are two things here: > > - events > - results > > And a question of what, if anything, each should be bound two. > > For the case in question, I think you're greatest concern is with > ensuring that the result of the request is clearly bound to the > command completion indication. With that in mind, would something > like: > > -breakpoint-create > =breakpoint-created,.... > =breakpoint-created,.... > ^done,breakpoint=1 > > be reasonable? It clearly binds the created breakpoint with the > request while at the same time doesn't treat the creation of this > breakpoint any different to the creation of any other breakpoint. Right. I think the principle should be that any command that has a direct result, that result should be reported in the "done" message of the command. I don't mind that it also get reported as an event. For instance, this means that if something like your listing above occurs, I know that the first breakpoint is the one I intended to make, and the second one, dunno about. This will be important, for instance, if we ever teach gdb that breaking on template source code generated a whole bunch of breakpoints. The GUI will want to gather up these breakpoints and treat them as a single bundle (since if the source line breakpoint is deleted in the UI, it will need to delete all these breakpoints). So knowing that one of the breakpoint-created events is some odd accident would be useful... > > I don't know how feasible it is to do this, mind. > Shouldn't be hard for the breakpoints, we do it already... > > > > > In short, you are breaking one of the core parts of the MI model, > for no very apparent reason. In this case, it might be benign, but it > is a very useful part of the design, and the reasons for doing it are > very weak. > > The MI was always going to have events and those events were going to > be separate from the results. As a simple example (from the 5.2.1 > doco): > http://sources.redhat.com/gdb/download/onlinedocs/gdb_24.html#SEC223 > > Command With Side Effects > -> -symbol-file xyz.exe > <- *breakpoint,nr="3",address="0x123",source="a.c:123" > <- (gdb) > > [sic - its missing a ^done]. One reason for this separation of event > and result is that we felt we could see far enough ahead to at least > realise that the MI would have to handle things like: > > -interpreter cli "break foo" > =breakpoint-created,... > ^done > > or even: > > -interpreter cli "source script" > =breakpoint-created,... > =breakpoint-deleted,... > =running > ^done > (gdb) > =stopped,... > =breakpoint-created,... > =running > (gdb) > > That is, in the general case, trying to tightly bind MI and events to > results wasn't going to be possible. > > Seems better to say that an mi command will usually have a well defined result, but may well have unintended consequences as well. We should be able to bind the result to the command token, but not the unintended consequences. It's actually not impossible to do that either, the original implementation that I did had all the event-like things added as tagged bits to the command result, unless they came after the command returned. But that's not the way Keith chose to implement it, which is fine. Of course, -interpreter-exec (is Keith changing this to -interpreter, or did you just type it wrong?) has NO well defined results. Everything is an unintended consequence. For convenience's sake, I think I report whether the command has started up the inferior or not, but even that could be gotten from events. Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <1033404264.17743.ezmlm@sources.redhat.com>]
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 [not found] <1033404264.17743.ezmlm@sources.redhat.com> @ 2002-09-30 17:48 ` Jim Ingham 2002-10-01 9:29 ` Andrew Cagney 0 siblings, 1 reply; 29+ messages in thread From: Jim Ingham @ 2002-09-30 17:48 UTC (permalink / raw) To: gdb-patches Hi, all... The changes from mi0 to mi1 were pretty trivial. So clients (in my case Project Builder) can fairly easily accommodate the removal of the mi0 interpreter. I am not suggesting that we reinstate that. However, the mi2 is shaping up to be a pretty big change (among other things, command results are differently reported in toto, as well as some command results changing format.) Converting PB from mi1 to mi2 is going to be a lot of work. And because of its nature, there is no a priori way to tell what all the clients are - and not all the clients will closely read the gdb-patches mailing list... Because of this, I am a little nervous at the easy way we are talking about deleting older versions of the mi. I think it is our responsibility to careful, and only release versions of the mi that we want to support, not the clients of the mi's responsibility to change their code every time we decide we are tired of supporting the test cases from one of the other versions we have previously promulgated... The mi loses much of its appeal if it means you are going to have to occasionally rework parts of your client that already work just fine, or suffer permanent fork-hood for your gdb. I agree with Daniel that we should hold off on declaring a real mi2 till we have something we are willing to support long term. And for the mi to be useful, I think we need to stick to only putting out named versions that we are willing to support. Jim > On Mon, Sep 30, 2002 at 11:03:55AM -0400, Andrew Cagney wrote: >> >>>>> >>>>> Are you planning to revert mi1 then? >>> >>>> >>>> Que? >>> >>> >>> "mi2" changes have been sneaking in. Are you planning to revert >>> them - >>> create an "mi1" which matches what mi1 actually was. >> >> It's a bit late for that. Someone should audit the changes made so >> far >> and identify which caused syntax changes and update accordingly. >> Fixes >> could, perhaphs be pushed into 5.3 (but I don't have the time). >> >>> Otherwise, where is the line drawn to mark the interface version as >>> final? It seems to me that the default shouldn't be evolving, that >>> -i=mi should default to a fixed point until the next version is >>> running. >> >> I think a line is drawn when each release is made. I'd expect an MI >> client to explicitly specify -i=miN (where N was formally released) >> rather than trust -i=mi. >> >> However, should the HEAD hold off on recognizing -i=mi2 until the next >> branch is cut? On the HEAD, -i=mi evolves by definition. However, >> -i=mi2 is evolving as well :-( > > That'd be best I think. I think that -i=mi2 specifies a fixed standard > and we don't have one yet; so how about -i=mi being different from > -i=mi1, but not adding -i=mi2 until we're ready to fix the interface? > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer > _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Jim Ingham jingham@apple.com Developer Tools - gdb ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-30 17:48 ` Jim Ingham @ 2002-10-01 9:29 ` Andrew Cagney 2002-10-01 10:34 ` Jim Ingham 0 siblings, 1 reply; 29+ messages in thread From: Andrew Cagney @ 2002-10-01 9:29 UTC (permalink / raw) To: Jim Ingham; +Cc: gdb-patches > Hi, all... > > The changes from mi0 to mi1 were pretty trivial. So clients (in my case Project Builder) can fairly easily accommodate the removal of the mi0 interpreter. I am not suggesting that we reinstate that. > > However, the mi2 is shaping up to be a pretty big change (among other things, command results are differently reported in toto, as well as some command results changing format.) Converting PB from mi1 to mi2 is going to be a lot of work. And because of its nature, there is no a priori way to tell what all the clients are - and not all the clients will closely read the gdb-patches mailing list... mi2 is bug fixes on mi1. However, at the same time it is gaining some of the missing functionality. Its just that more bugs and more missing functionality are being worked on. To put it simply, about time! cf the patch to pr gdb/672 where the output was straight bogus (it contained the equivalent of {name="foo", name="bar", name="baz"}. JeffJ has been asked to preserve the old (broken) behavior. I should note it was very tempting to not make this request since the old behavior was broken and should have been bug-reported and fixed long long ago. > Because of this, I am a little nervous at the easy way we are talking about deleting older versions of the mi. I think it is our responsibility to careful, and only release versions of the mi that we want to support, not the clients of the mi's responsibility to change their code every time we decide we are tired of supporting the test cases from one of the other versions we have previously promulgated... The mi loses much of its appeal if it means you are going to have to occasionally rework parts of your client that already work just fine, or suffer permanent fork-hood for your gdb. I was ment to delete mi0 something like a year ago. I'm running a little late on that one :-) > I agree with Daniel that we should hold off on declaring a real mi2 till we have something we are willing to support long term. And for the mi to be useful, I think we need to stick to only putting out named versions that we are willing to support. Part of the nature of GDB is that it is constantly evolving. MI is going to be (like it or not) part of that evolution. Each new GDB release will see enhancements and bug fixes and MI uses will need to be accomodating to that. In return for this accomodation GDB are trying to preserve a given MI interface for at least two release cycles. Part of is the very strong emphasis on testcases and documentation. If you feel that things are lacking in this area then, perhaphs something to contribute to, is the documentation and testing infrastructure for MI (did the apple droppings contain any new tests?). Over time, the MI interface should also stablize. Andrew ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-01 9:29 ` Andrew Cagney @ 2002-10-01 10:34 ` Jim Ingham 2002-10-01 13:25 ` Andrew Cagney 0 siblings, 1 reply; 29+ messages in thread From: Jim Ingham @ 2002-10-01 10:34 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb-patches Andrew, On Tuesday, October 1, 2002, at 09:29 AM, Andrew Cagney wrote: >> Hi, all... >> The changes from mi0 to mi1 were pretty trivial. So clients (in my >> case Project Builder) can fairly easily accommodate the removal of >> the mi0 interpreter. I am not suggesting that we reinstate that. >> However, the mi2 is shaping up to be a pretty big change (among other >> things, command results are differently reported in toto, as well as >> some command results changing format.) Converting PB from mi1 to mi2 >> is going to be a lot of work. And because of its nature, there is >> no a priori way to tell what all the clients are - and not all the >> clients will closely read the gdb-patches mailing list... > > mi2 is bug fixes on mi1. However, at the same time it is gaining some > of the missing functionality. Its just that more bugs and more > missing functionality are being worked on. To put it simply, about > time! Well, mi1 was a moving target, so "bug fixes on mi1" is a little hard to quantify. But the change that Keith proposed - which started off the bump to mi2 discussion - was to move command result reporting for things like -break-insert from the ^done to the gdb event. This has a big effect on how a client uses the mi. > > cf the patch to pr gdb/672 where the output was straight bogus (it > contained the equivalent of {name="foo", name="bar", name="baz"}. > JeffJ has been asked to preserve the old (broken) behavior. I should > note it was very tempting to not make this request since the old > behavior was broken and should have been bug-reported and fixed long > long ago. > >> Because of this, I am a little nervous at the easy way we are talking >> about deleting older versions of the mi. I think it is our >> responsibility to careful, and only release versions of the mi that >> we want to support, not the clients of the mi's responsibility to >> change their code every time we decide we are tired of supporting the >> test cases from one of the other versions we have previously >> promulgated... The mi loses much of its appeal if it means you are >> going to have to occasionally rework parts of your client that >> already work just fine, or suffer permanent fork-hood for your gdb. > > I was ment to delete mi0 something like a year ago. I'm running a > little late on that one :-) > >> I agree with Daniel that we should hold off on declaring a real mi2 >> till we have something we are willing to support long term. And for >> the mi to be useful, I think we need to stick to only putting out >> named versions that we are willing to support. > > Part of the nature of GDB is that it is constantly evolving. MI is > going to be (like it or not) part of that evolution. Each new GDB > release will see enhancements and bug fixes and MI uses will need to > be accomodating to that. This is only partly true. We are actually pretty conservative about changing command output. We haven't broken annotate for a while, IIRC. The mi is more like the command output, and I think we should have the same level of conservatism about this. > > In return for this accomodation GDB are trying to preserve a given MI > interface for at least two release cycles. Part of is the very strong > emphasis on testcases and documentation. If you feel that things are > lacking in this area then, perhaphs something to contribute to, is the > documentation and testing infrastructure for MI (did the apple > droppings contain any new tests?). No, we haven't worked on this. It is something we know we need to do, but for now we have been using Project Builder as our mi tester (it exercises a fair bit of the functionality, and catches most of the things we break). > > Over time, the MI interface should also stablize. > I agree. I am just arguing that we should mark stable points and then think hard before we delete them. Otherwise while it is waiting to stabilize, folks will be reasonably a little chary about using it... Jim -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-01 10:34 ` Jim Ingham @ 2002-10-01 13:25 ` Andrew Cagney 2002-10-01 14:01 ` Jim Ingham 0 siblings, 1 reply; 29+ messages in thread From: Andrew Cagney @ 2002-10-01 13:25 UTC (permalink / raw) To: Jim Ingham; +Cc: gdb-patches > This is only partly true. We are actually pretty conservative about changing command output. We haven't broken annotate for a while, IIRC. The mi is more like the command output, and I think we should have the same level of conservatism about this. One of the motivations behind the MI output was that a parser could be written in a way that allowed it to discard anything it didn't recognize. For instance: additional events, or additional output fields should both simply be discarded. They shouldn't be viewed as MI changes. The thing that is triggering mi2 is the changes to actual responses (breakpoints as you pointed out but also others.). Anyway, at the time of each GDB release, a decision should be made about freezing the current MI interface and starting a new one. Here, we've frozen mi1 and moved onto mi2's development. At some point in the future mi2 will be frozen and development will move to mi3 (I strongly suspect it will be pretty quick - 5.4/6.0). After a freeze, the old syntax should hang around for a limited period of time. The pratical translation of this is ``how long before the mi1-*.exp files can be deleted''? My guess is two releases - here 5.3 and 5.4/6.0. That means that 5.5/6.0 (in roughly a year) there will be released a GDB that doesn't support "mi1" -- for GDB I think that is a long time! Andrew ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-01 13:25 ` Andrew Cagney @ 2002-10-01 14:01 ` Jim Ingham 2002-10-01 15:10 ` Andrew Cagney 0 siblings, 1 reply; 29+ messages in thread From: Jim Ingham @ 2002-10-01 14:01 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb-patches Andrew, On Tuesday, October 1, 2002, at 01:25 PM, Andrew Cagney wrote: >> This is only partly true. We are actually pretty conservative about >> changing command output. We haven't broken annotate for a while, >> IIRC. The mi is more like the command output, and I think we should >> have the same level of conservatism about this. > > One of the motivations behind the MI output was that a parser could be > written in a way that allowed it to discard anything it didn't > recognize. > > For instance: additional events, or additional output fields should > both simply be discarded. They shouldn't be viewed as MI changes. > > The thing that is triggering mi2 is the changes to actual responses > (breakpoints as you pointed out but also others.). > > Anyway, at the time of each GDB release, a decision should be made > about freezing the current MI interface and starting a new one. Here, > we've frozen mi1 and moved onto mi2's development. At some point in > the future mi2 will be frozen and development will move to mi3 (I > strongly suspect it will be pretty quick - 5.4/6.0). After a freeze, > the old syntax should hang around for a limited period of time. I am a little confused here. One of the design points for the MI is the ability to add information to the commands without requiring a change in the clients (unless, of course, they wanted to use the new information). That should mean that we have set up a situation where we can change the mi in substantial ways without having to demand that clients rewrite their code to use MI. Shouldn't that mean that we can go a long way without having to make incompatible changes? And so, imposing the burden on ourselves of not jerking clients around all the time would not be such a big deal, and perhaps worth the inconvenience it would cause the MI developers? > > The pratical translation of this is ``how long before the mi1-*.exp > files can be deleted''? My guess is two releases - here 5.3 and > 5.4/6.0. That means that 5.5/6.0 (in roughly a year) there will be > released a GDB that doesn't support "mi1" -- for GDB I think that is > a long time! As a client of the MI, this means that in a year or so I have to expect to rewrite code that works just fine, because you have deleted the support for it from gdb; or carry the burden of maintaining mi1 as patches to the gdb sources. And longer term, I can expect to do this again next year, unless things "stabilize" before then, which they may or may not do. This doesn't sound appetizing to me. The MI is a public interface to gdb - and the only really useful one we offer to external clients who are not Human beings right now. It has been around in gdb, and we have been using it contentedly, for a couple of years now. A retroactively stated policy of instability in this interface (including the vanishing of useful variants at odd intervals) seems very unfair to those who have been using it right along, as well as being one which can only slow its uptake in general. Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-01 14:01 ` Jim Ingham @ 2002-10-01 15:10 ` Andrew Cagney 2002-10-01 15:46 ` Jim Ingham 0 siblings, 1 reply; 29+ messages in thread From: Andrew Cagney @ 2002-10-01 15:10 UTC (permalink / raw) To: Jim Ingham; +Cc: gdb-patches > I am a little confused here. One of the design points for the MI is the ability to add information to the commands without requiring a change in the clients (unless, of course, they wanted to use the new information). That should mean that we have set up a situation where we can change the mi in substantial ways without having to demand that clients rewrite their code to use MI. Shouldn't that mean that we can go a long way without having to make incompatible changes? And so, imposing the burden on ourselves of not jerking clients around all the time would not be such a big deal, and perhaps worth the inconvenience it would cause the MI developers? Yes, that's the theory. There are always problems though: - for some commands, their output is simply bogus. See gdb/672 > > - var-update syntax is: ^done,changelist={name="var3",in_scope="true",type_changed="false", name="var2",in_scope="true",type_changed="false"} Notice how a single tuple contains several "name" fields :-( JeffJ's currently comming up with a patch that will preserve the current behavior. - some parts of the interface were technically flawed. The breakpoint event stuff that KeithS changed (but not in a backward compatible way :-(). Not fixing this, further entrenches a flawed model :-( The only error in that change was not preserving the old output when mi1 :-( Fixing either of these involves significant change to MI's output, but it, I think, is for the better. > As a client of the MI, this means that in a year or so I have to expect to rewrite code that works just fine, because you have deleted the support for it from gdb; or carry the burden of maintaining mi1 as patches to the gdb sources. And longer term, I can expect to do this again next year, unless things "stabilize" before then, which they may or may not do. This doesn't sound appetizing to me. > > The MI is a public interface to gdb - and the only really useful one we offer to external clients who are not Human beings right now. It has been around in gdb, and we have been using it contentedly, for a couple of years now. A retroactively stated policy of instability in this interface (including the vanishing of useful variants at odd intervals) seems very unfair to those who have been using it right along, as well as being one which can only slow its uptake in general. What we're seeing here is the fallout that results from a number of players creating localized GDBs. GDB developers have started looking at the underlying problems that Apple and others encountered, and are trying to fix them. Regretably, per above, this is going to need some short term change. It is just a shame that this process wasn't started long ago. Andrew ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-01 15:10 ` Andrew Cagney @ 2002-10-01 15:46 ` Jim Ingham 2002-10-01 16:39 ` Keith Seitz 0 siblings, 1 reply; 29+ messages in thread From: Jim Ingham @ 2002-10-01 15:46 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb-patches Andrew, On Tuesday, October 1, 2002, at 03:10 PM, Andrew Cagney wrote: >> I am a little confused here. One of the design points for the MI is >> the ability to add information to the commands without requiring a >> change in the clients (unless, of course, they wanted to use the new >> information). That should mean that we have set up a situation where >> we can change the mi in substantial ways without having to demand >> that clients rewrite their code to use MI. Shouldn't that mean that >> we can go a long way without having to make incompatible changes? >> And so, imposing the burden on ourselves of not jerking clients >> around all the time would not be such a big deal, and perhaps worth >> the inconvenience it would cause the MI developers? > > Yes, that's the theory. There are always problems though: > > - for some commands, their output is simply bogus. See gdb/672 > > > - var-update syntax is: > ^done,changelist={name="var3",in_scope="true",type_changed="false", > name="var2",in_scope="true",type_changed="false"} > Notice how a single tuple contains several "name" fields :-( JeffJ's > currently comming up with a patch that will preserve the current > behavior. This was putatively bogus, but very easy to parse. It didn't even annoy Rab, when he was first doing this... > > - some parts of the interface were technically flawed. > The breakpoint event stuff that KeithS changed (but not in a backward > compatible way :-(). Not fixing this, further entrenches a flawed > model :-( The only error in that change was not preserving the old > output when mi1 :-( BTW, I haven't seen the actual change Keith is planning here. Will he be sticking the command sequence cookie in the async result? His example didn't show the cookies. Seems to me that reporting command results as an async notification means that we are breaking the tie between the command and its results. It was very nice that I could issue a bunch of commands at some point in the GUI code, then at another place gather up the results, and match them to the initial commands by using the sequence ID's. In the new way of doing things, we have to parse more carefully, and assume that the =breakpoint-create that we just got was the one that came from the -break-insert in the output just above it. It makes the client stream parser have to be more stateful that in the mi0 version, which doesn't seem to me all that good an idea. If the async event has the cookie in it, this will be a little better, though it still means I have a two-step accumulation phase for each command (wait for the async result with the right cookie, then the done with the right cookie...) > > Fixing either of these involves significant change to MI's output, but > it, I think, is for the better. > >> As a client of the MI, this means that in a year or so I have to >> expect to rewrite code that works just fine, because you have deleted >> the support for it from gdb; or carry the burden of maintaining mi1 >> as patches to the gdb sources. And longer term, I can expect to do >> this again next year, unless things "stabilize" before then, which >> they may or may not do. This doesn't sound appetizing to me. >> The MI is a public interface to gdb - and the only really useful one >> we offer to external clients who are not Human beings right now. It >> has been around in gdb, and we have been using it contentedly, for a >> couple of years now. A retroactively stated policy of instability in >> this interface (including the vanishing of useful variants at odd >> intervals) seems very unfair to those who have been using it right >> along, as well as being one which can only slow its uptake in >> general. > > What we're seeing here is the fallout that results from a number of > players creating localized GDBs. GDB developers have started looking > at the underlying problems that Apple and others encountered, and are > trying to fix them. Regretably, per above, this is going to need some > short term change. Just because K&R C kind of sucked, however, doesn't mean that most compiler vendors got to drop support for it... Alternatively, I don't know why the planning model for the changes seems to be - we will change a bit, declare a version, change a bit more, declare another incompatible version and drop the first version, rinse and repeat... In the face of the fact that you most unfortunately have users already, I think you should decide to work out the changes for whatever time it takes for you to come up with a version you are happy with, then stick with that for a product lifecycle-type-timescale, not a patch release timescale. That way people who plan to use this stuff can actually plan their use of it... Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-01 15:46 ` Jim Ingham @ 2002-10-01 16:39 ` Keith Seitz 2002-10-01 17:45 ` Jim Ingham ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Keith Seitz @ 2002-10-01 16:39 UTC (permalink / raw) To: Jim Ingham; +Cc: Andrew Cagney, gdb-patches On Tue, 1 Oct 2002, Jim Ingham wrote: > BTW, I haven't seen the actual change Keith is planning here. Will he > be sticking the command sequence cookie in the async result? His > example didn't show the cookies. For the record, the proposed change would look like: (gdb) 200-break-insert main =breakpoint-create,number="1" 200^done (gdb) > Seems to me that reporting command results as an async notification > means that we are breaking the tie between the command and its results. And is that necessarily bad? (More on my confusion below...) > It was very nice that I could issue a bunch of commands at some point > in the GUI code, then at another place gather up the results, and match > them to the initial commands by using the sequence ID's. I'm afraid that I'm not following. Could you please expound? Why would you want a tight coupling of commands and their results? What's wrong with just issuing a command at GDB and waiting for GDB to tell you that it's done something? It seems to me that the less serialization that a UI does, the more time it has to spend in its event loop and the more responsive it will feel to the user (barring the java way: create a freakin' thread for everything). > In the new way of doing things, we have to parse more carefully, and > assume that the =breakpoint-create that we just got was the one that > came from the -break-insert in the output just above it. It makes the > client stream parser have to be more stateful that in the mi0 version, > which doesn't seem to me all that good an idea. If the async event has > the cookie in it, this will be a little better, though it still means I > have a two-step accumulation phase for each command (wait for the async > result with the right cookie, then the done with the right cookie...) Ditto the above. Maybe -break-insert and =breakpoint-create are bad examples(?), but I am not able to imagine why it would matter which command elicited the notification. Commands are issued, and something happens. The only case I can imagine where this is important is when an error occurs setting the breakpoint, but MI will (and will continue) to report errors immediately. Maybe something related to async targets? (BTW, there is no reason why I/we cannot/could not put the old behavior back for an MI0 target, if 'mi0' were sticking around, which is a decision I want nothing to do with, actually.) One is still pretty screwed, though, when "interpreter-exec" is used, unless we revert from async notification back to serial notification via hook hack that you're using. <devil's advocate> As far as the versioning thing goes, I must say that I don't really care, (not that my opinion matters), but I can understand why some on this list would be less sympathetic with objections to dropping mi0 coming from Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot of stuff, but only managed to "submit" a giant distribution tarball of their modified GDB. I wouldn't be too suprised if some thought that Apple was taking advantage of the public's work. Mind you, I'm not saying that any of this is true, but I wouldn't be suprised if some one reading this list felt that way. </devil's advocate> Keith ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-01 16:39 ` Keith Seitz @ 2002-10-01 17:45 ` Jim Ingham 2002-10-02 7:58 ` Keith Seitz 2002-10-01 23:25 ` Jason Molenda 2002-10-02 10:22 ` Stan Shebs 2 siblings, 1 reply; 29+ messages in thread From: Jim Ingham @ 2002-10-01 17:45 UTC (permalink / raw) To: Keith Seitz; +Cc: Andrew Cagney, gdb-patches Keith, On Tuesday, October 1, 2002, at 04:42 PM, Keith Seitz wrote: > On Tue, 1 Oct 2002, Jim Ingham wrote: > >> BTW, I haven't seen the actual change Keith is planning here. Will he >> be sticking the command sequence cookie in the async result? His >> example didn't show the cookies. > > For the record, the proposed change would look like: > > (gdb) > 200-break-insert main > =breakpoint-create,number="1" > 200^done > (gdb) > >> Seems to me that reporting command results as an async notification >> means that we are breaking the tie between the command and its >> results. > > And is that necessarily bad? (More on my confusion below...) > >> It was very nice that I could issue a bunch of commands at some >> point >> in the GUI code, then at another place gather up the results, and >> match >> them to the initial commands by using the sequence ID's. > > I'm afraid that I'm not following. Could you please expound? Why would > you want a tight coupling of commands and their results? What's wrong > with > just issuing a command at GDB and waiting for GDB to tell you that > it's done something? It seems to me that the less serialization that a > UI > does, the more time it has to spend in its event loop and the more > responsive it will feel to the user (barring the java way: create a > freakin' thread for everything). I don't want a tight coupling in TIME, or in the output sequence. I want meta-info which tells me with 100% certainty that this result is the result of command foo, that I sent some time in the past, precisely so I DON'T have to rely on anything about the sequencing of input or output to make this connection. Suppose I have a canned startup sequence that I send to gdb when the user starts up. This startup sequence sets a bunch of environment variables, does some other accounting and also retrieves the saved breakpoint list from the project, and sends those to the target. In the PB code, we make a bunch of command objects - one for each of these commands - put them on a queue of outstanding commands, stick the actual gdb command in a buffer, then fire the whole lot off to gdb. Then we sit at the other end of the communication loop sucking commands back from gdb. Each time we get a result, we use the cookie to match it to the command object, give the command object its data, and it does whatever it needs with it (for instance, create a real breakpoint object, and stick it in our list of breakpoints). Doing this is very straightforward, we can always map the results to the command that sent them with NO guesswork. And anything else that shows up is some asynchronous result that can be treated specially - some error condition or whatever. As soon as I have to guess the connection between results from gdb and the command that originated them by position in the gdb output stream, this very nice model breaks down. > >> In the new way of doing things, we have to parse more carefully, and >> assume that the =breakpoint-create that we just got was the one that >> came from the -break-insert in the output just above it. It makes the >> client stream parser have to be more stateful that in the mi0 version, >> which doesn't seem to me all that good an idea. If the async event >> has >> the cookie in it, this will be a little better, though it still means >> I >> have a two-step accumulation phase for each command (wait for the >> async >> result with the right cookie, then the done with the right cookie...) > > Ditto the above. Maybe -break-insert and =breakpoint-create are bad > examples(?), but I am not able to imagine why it would matter which > command elicited the notification. Commands are issued, and something > happens. The only case I can imagine where this is important is when > an error occurs setting the breakpoint, but MI will (and will > continue) to report errors immediately. In the break case, on the UI side I have something that, until I get the breakpoint number back from gdb, I can't do anything with. At the time I issue the breakpoint command, I can't make a complete break object on the GUI side. So a very convenient way to handle this is just to tell myself I have a pending command, and when the result comes back, actually make the now useful breakpoint object. If the command results have the command cookie in them, I just wait till I get that cookie back, suck the data in and make the breakpoint object. In your new method, I have to keep a more careful eye on the output stream, fish the =breakpoint-create off the stream, know somehow (either because I only ever get to have one outstanding breakpoint, or because I keep a list of breakpoints in order of issuing) which command it actually goes to, continue to wait for the ^done - 'cause there's many a slip..., then finally make the object. Much more tedious. Plus, what if there is an error? Then presumably I will get the ^error, but NOT the =breakpoint-create... The other way to do it, is just to issue a bunch of stuff down the pipe, but not build any objects watching for results. Then I hang around on the UI side going "Oh, boy, I just got a breakpoint, yuk, yuk..." and make the object. Not very reliable, however. You are just making life much harder for the client. It is REALLY nice to have results match up with commands. You want to minimize knowledge of the output flow, and your method of doing things actually requires more knowledge... The more I think about it the worse idea it appears to me... > > Maybe something related to async targets? (BTW, there is no reason why > I/we cannot/could not put the old behavior back for an MI0 target, if > 'mi0' were sticking around, which is a decision I want nothing to do > with, actually.) One is still pretty screwed, though, when > "interpreter-exec" is used, unless we revert from async notification > back > to serial notification via hook hack that you're using. > > <devil's advocate> > As far as the versioning thing goes, I must say that I don't really > care, > (not that my opinion matters), but I can understand why some on this > list > would be less sympathetic with objections to dropping mi0 coming from > Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot > of > stuff, but only managed to "submit" a giant distribution tarball of > their > modified GDB. I wouldn't be too suprised if some thought that Apple was > taking advantage of the public's work. Mind you, I'm not saying that > any > of this is true, but I wouldn't be suprised if some one reading this > list > felt that way. > </devil's advocate> This is unhelpful. The real point is that you CAN'T know who all the users of the MI are. If the MI is well done, they never need tell you that they are using it, nor should they. And requiring anyone planning to use the MI to follow gdb-patches closely that they might know when their software is likely to stop working is silly. Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-01 17:45 ` Jim Ingham @ 2002-10-02 7:58 ` Keith Seitz 2002-10-02 10:49 ` Jim Ingham 0 siblings, 1 reply; 29+ messages in thread From: Keith Seitz @ 2002-10-02 7:58 UTC (permalink / raw) To: Jim Ingham; +Cc: gdb-patches On Tue, 1 Oct 2002, Jim Ingham wrote: > I don't want a tight coupling in TIME, or in the output sequence. I > want meta-info which tells me with 100% certainty that this result is > the result of command foo, that I sent some time in the past, precisely > so I DON'T have to rely on anything about the sequencing of input or > output to make this connection. Ok, but this is exactly what I don't understand: what does it matter where the breakpoint comes from? All that matters is that you have issued a command, and you don't do anything out of the normaluntil an event from GDB telling you that it has set a breakpoint. You just sit in your event loop waiting for any event (GUI, paint, GDB, blah blah blah). Insight has used a method exactly like this now for over a year. When a breakpoint is set, Insight tells gdb to set it. It then returns to the command loop. It doesn't do anything else. It's not waiting for anything. When the breakpoint event comes from gdb, it creates its breakpoint object and passes it around. The source window gets it and places a breakpoint at the appropriate place. I can only assume that you've got private data that you need to associate with commands and that this data is lost when returning to the event loop. Please help me understand why it is so important to know exactly what command prompted a breakpoint event. I still just don't get it. Can you give me a specific example of when it would be useful to know that command A elicited breakpoint event A' instead of command B? Sorry. Keith ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-02 7:58 ` Keith Seitz @ 2002-10-02 10:49 ` Jim Ingham 2002-10-25 14:48 ` Andrew Cagney 0 siblings, 1 reply; 29+ messages in thread From: Jim Ingham @ 2002-10-02 10:49 UTC (permalink / raw) To: Keith Seitz; +Cc: gdb-patches On Wednesday, October 2, 2002, at 08:01 AM, Keith Seitz wrote: > On Tue, 1 Oct 2002, Jim Ingham wrote: > >> I don't want a tight coupling in TIME, or in the output sequence. I >> want meta-info which tells me with 100% certainty that this result is >> the result of command foo, that I sent some time in the past, >> precisely >> so I DON'T have to rely on anything about the sequencing of input or >> output to make this connection. > > Ok, but this is exactly what I don't understand: what does it matter > where > the breakpoint comes from? All that matters is that you have issued a > command, and you don't do anything out of the normaluntil an event from > GDB telling you that it has set a breakpoint. You just sit in your > event > loop waiting for any event (GUI, paint, GDB, blah blah blah). In large part, it is just that if I can track cause & effect unambiguously, everything is much cleaner. From PB, I issue a command, I want to tick off when that command succeeded, and gather all the data from the result I need. If I get a note back from gdb saying, "The third command down in the command stream that you issued, here is the result to it." then I can do this without any effort. However, in your proposed implementation, I have to peer at the command stream and wait both for an anonymous breakpoint created message, and a for the done message (to know things are formally done, and because it would be very dangerous to just toss aside bits of the output stream, since it reduces your chances of catching & handling errors intelligently.) Then I have to use some smarts to tie the breakpoint created message to the particular message I sent to gdb. This is harder to do, and fragile. In my mind, one of the major advantages of the MI was that it made this tie between the command you sent and the result that came from it explicit and unambiguous. This was in response to a lot of the pain that we suffered in insight where any random spew from the command line would get itself inserted into the "results" of the command you thought you were executing. You are breaking this tie by moving the results of a command from the command result to an untagged asynchronous event. For breakpoints, this is probably just an inconvenience. But if we follow this as a principle, then in more complex cases, where it is not so easy to tell whether an asynchronous notification arose from a command initiated by the MI, or from some other action we will likely start getting confused again. For instance, we might have something happening in the target, or some console command, or something more gnarly like the results of a breakpoint command which also continued the target while you thought it was just running... In short, you are breaking one of the core parts of the MI model, for no very apparent reason. In this case, it might be benign, but it is a very useful part of the design, and the reasons for doing it are very weak. > > Insight has used a method exactly like this now for over a year. When a > breakpoint is set, Insight tells gdb to set it. It then returns to the > command loop. It doesn't do anything else. It's not waiting for > anything. > When the breakpoint event comes from gdb, it creates its breakpoint > object > and passes it around. The source window gets it and places a > breakpoint at > the appropriate place. I can only assume that you've got private data > that > you need to associate with commands and that this data is lost when > returning to the event loop. Not quite. Rather we want to issue commands in batches, and then link the results of the commands back up to the individual commands. This is often a very convenient way to proceed. And I would rather have the linkage be explicit, because matching the commands to results by inspecting the sequencing of the result is fragile and error-prone. > > Please help me understand why it is so important to know exactly what > command prompted a breakpoint event. I still just don't get it. Can you > give me a specific example of when it would be useful to know that > command > A elicited breakpoint event A' instead of command B? Remember that PB persists over individual runs of the gdb debugger (and can, in fact, be running multiple copies of gdb, one for each project). Also,we keep a Breakpoints window that persists between runs of PB, so the user can have all his/her favorite breakpoints persist over PB sessions. So we have to have an object on the PB side that represents each breakpoint before we have even thought about starting up gdb. Each one of these PB breakpoints is going to result in a gdb breakpoint at some time. When I go to take the PB breakpoint object & insert it into the current instance of the gdb debugger, I would like to get the right breakpoint number back into the associated PB breakpoint object. I can very easily do this if I can tie the results of the command that sends the breakpoint to gdb to the initial command. Otherwise I have to do unnecessary work whose only benefit is it gives me a chance to make a mistake somewhere. Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-02 10:49 ` Jim Ingham @ 2002-10-25 14:48 ` Andrew Cagney 0 siblings, 0 replies; 29+ messages in thread From: Andrew Cagney @ 2002-10-25 14:48 UTC (permalink / raw) To: Jim Ingham; +Cc: Keith Seitz, gdb-patches [Did anyone mention that Apple's mail tool is officially weird?] [was a good holiday] >> On Wednesday, October 2, 2002, at 08:01 AM, Keith Seitz wrote: >> >>> On Tue, 1 Oct 2002, Jim Ingham wrote: >>> >>> I don't want a tight coupling in TIME, or in the output sequence. I >>> want meta-info which tells me with 100% certainty that this result is >>> the result of command foo, that I sent some time in the past, precisely >>> so I DON'T have to rely on anything about the sequencing of input or >>> output to make this connection. > >> >> Ok, but this is exactly what I don't understand: what does it matter where >> the breakpoint comes from? All that matters is that you have issued a >> command, and you don't do anything out of the normaluntil an event from >> GDB telling you that it has set a breakpoint. You just sit in your event >> loop waiting for any event (GUI, paint, GDB, blah blah blah). > > In large part, it is just that if I can track cause & effect unambiguously, everything is much cleaner. From PB, I issue a command, I want to tick off when that command succeeded, and gather all the data from the result I need. If I get a note back from gdb saying, "The third command down in the command stream that you issued, here is the result to it." then I can do this without any effort. However, in your proposed implementation, I have to peer at the command stream and wait both for an anonymous breakpoint created message, and a for the done message (to know things are formally done, and because it would be very dangerous to just toss aside bits of the output stream, since it reduces your chances of catching & handling errors intelligently.) Then I have to use some smarts to tie the breakpoint created message to the particular message I sent to gdb. This is harder to do, and fragile. > In my mind, one of the major advantages of the MI was that it made this tie between the command you sent and the result that came from it explicit and unambiguous. This was in response to a lot of the pain that we suffered in insight where any random spew from the command line would get itself inserted into the "results" of the command you thought you were executing. You are breaking this tie by moving the results of a command from the command result to an untagged asynchronous event. For breakpoints, this is probably just an inconvenience. But if we follow this as a principle, then in more complex cases, where it is not so easy to tell whether an asynchronous notification arose from a command initiated by the MI, or from some other action we will likely start getting confused again. For instance, we might have something happening in the target, or some console command, or something more gnarly like the results of a breakpoint command which also continued the target wh ile you thought it was just running... You mean like http://sources.redhat.com/gdb/papers/libgdb2/wp/gdbtk2.jpg There are two things here: - events - results And a question of what, if anything, each should be bound two. For the case in question, I think you're greatest concern is with ensuring that the result of the request is clearly bound to the command completion indication. With that in mind, would something like: -breakpoint-create =breakpoint-created,.... =breakpoint-created,.... ^done,breakpoint=1 be reasonable? It clearly binds the created breakpoint with the request while at the same time doesn't treat the creation of this breakpoint any different to the creation of any other breakpoint. I don't know how feasible it is to do this, mind. > > In short, you are breaking one of the core parts of the MI model, for no very apparent reason. In this case, it might be benign, but it is a very useful part of the design, and the reasons for doing it are very weak. The MI was always going to have events and those events were going to be separate from the results. As a simple example (from the 5.2.1 doco): http://sources.redhat.com/gdb/download/onlinedocs/gdb_24.html#SEC223 Command With Side Effects -> -symbol-file xyz.exe <- *breakpoint,nr="3",address="0x123",source="a.c:123" <- (gdb) [sic - its missing a ^done]. One reason for this separation of event and result is that we felt we could see far enough ahead to at least realise that the MI would have to handle things like: -interpreter cli "break foo" =breakpoint-created,... ^done or even: -interpreter cli "source script" =breakpoint-created,... =breakpoint-deleted,... =running ^done (gdb) =stopped,... =breakpoint-created,... =running (gdb) That is, in the general case, trying to tightly bind MI and events to results wasn't going to be possible. Andrew ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-01 16:39 ` Keith Seitz 2002-10-01 17:45 ` Jim Ingham @ 2002-10-01 23:25 ` Jason Molenda 2002-10-02 10:22 ` Stan Shebs 2 siblings, 0 replies; 29+ messages in thread From: Jason Molenda @ 2002-10-01 23:25 UTC (permalink / raw) To: Keith Seitz; +Cc: Jim Ingham, Andrew Cagney, gdb-patches On Tue, Oct 01, 2002 at 04:42:28PM -0700, Keith Seitz wrote: > <devil's advocate> >[...] > Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot of > stuff, but only managed to "submit" a giant distribution tarball of their > modified GDB. I wouldn't be too suprised if some thought that Apple was > taking advantage of the public's work. Mind you, I'm not saying that any > of this is true, but I wouldn't be suprised if some one reading this list > felt that way. > </devil's advocate> This is definitely off-topic and I should just let it go... But this isn't a fair representation of reality. I think Keith knows it, and I think all the gdb folks who know Jim know it. The gdb group at Apple is not large and has had tremendous struggles to get gdb working correctly for its developers on the MacOS X platform -- there has been literally no time left over. Apple management is very supportive of moving our fixes, enhancements and changes to the FSF as much as possible -- as anyone would sensibly be -- but it's a simple matter of not having the time to make it happen so far. As for the source dump, you know very well that Andrew asked for that, and I provided it right away. (Incidentally, I'm not one of these hard-working Apple gdb programmers, and even I couldn't find time to make up the original tarball until a weekend.) I think you can see Apple's committment to working with the free software community in gcc more easily -- we've got more people working on the compiler there and it is an obvious priority to participate in the compiler's development and enhancement. The compiler and debugger groups are under the same management structure - they're clued in that this is a necessary way to operate in the long term. Back in the day, Cygnus was periodically flamed for being evil software hoarders by various unclueful people because we weren't releasing our local changes in the timeframe or manner that the flamers wanted us to. Keith, you should know better. Jason ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-10-01 16:39 ` Keith Seitz 2002-10-01 17:45 ` Jim Ingham 2002-10-01 23:25 ` Jason Molenda @ 2002-10-02 10:22 ` Stan Shebs 2 siblings, 0 replies; 29+ messages in thread From: Stan Shebs @ 2002-10-02 10:22 UTC (permalink / raw) To: Keith Seitz; +Cc: Jim Ingham, Andrew Cagney, gdb-patches Keith Seitz wrote: > ><devil's advocate> >As far as the versioning thing goes, I must say that I don't really care, >(not that my opinion matters), but I can understand why some on this list >would be less sympathetic with objections to dropping mi0 coming from >Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot of >stuff, but only managed to "submit" a giant distribution tarball of their >modified GDB. I wouldn't be too suprised if some thought that Apple was >taking advantage of the public's work. Mind you, I'm not saying that any >of this is true, but I wouldn't be suprised if some one reading this list >felt that way. ></devil's advocate> > If you're saying it, then there are probably others thinking it, and so I'll respond that this is both unfair and ignorant. Apple is the only major system vendor using GCC and GDB as their primary development tools, and we have a set of considerations not seen by GNU/Linux, Cisco, HP, etc. For instance, we have massive legacy, both from NeXT and from the old MacOS world. We also have hundreds of fulltime engineers who can't get their jobs done if GDB doesn't, say, display a thread local variable correctly. We also have to provide tools for external developers coming from the various existing Mac environments, such as MPW and CW, many of them have expectations vastly different than what GNU traditionally provides, and if you tell them "tough", then they stop developing for the Mac, which is not acceptable. I've dealt with this for a couple years in the GCC context, and the situation is that even if we were to offer every single local change, many of them would be turned down, which means that we always have a constant overhead time to maintain our changes, depending on the churn in FSF code. So when we have to deal with gratuitous change, that eats into the time that could have been spent making patches for submission. It's a real chicken-and-egg problem, and in the compiler group we've been fortunate in having extra people to do some of this work while still meeting our other obligations. So let's all stay honest and aboveboard about what we're all doing and why, and in turn not impugn the motives and activities of our colleagues. We can accomplish a lot more working with rather than against each other. Stan ^ permalink raw reply [flat|nested] 29+ messages in thread
* [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0
@ 2002-09-29 11:14 Andrew Cagney
2002-09-29 12:55 ` Daniel Jacobowitz
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Andrew Cagney @ 2002-09-29 11:14 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 249 bytes --]
Hello,
The attached patch updates things so that "mi2" is the default MI
syntax. I need to add a mechanism so that the MI code can query the
version but I'll post that separatly.
It modifies NEWS (comments?).
It updates the doco (ok?).
Andrew
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 5664 bytes --]
Index: ChangeLog
2002-09-29 Andrew Cagney <ac131313@redhat.com>
* NEWS: Mention that MI syntax changed to "mi2" and that "mi0"
syntax has been removed.
Index: doc/ChangeLog
2002-09-29 Andrew Cagney <ac131313@redhat.com>
* gdb.texinfo (Mode Options): Update --interpreter option. "mi2"
and "mi1" instead of "mi1" and "mi0".
Index: mi/ChangeLog
2002-09-29 Andrew Cagney <ac131313@redhat.com>
* mi-main.c (mi2_command_loop): New function.
(mi0_command_loop): Delete function.
(_initialize_mi_main): Recognize, and default to, "mi2". Do not
recognize "mi0".
* mi-out.c (mi_table_begin): Remove mi0 code.
(mi_table_body, mi_table_end): Ditto.
(mi_table_header, mi_open, mi_close): Ditto.
Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.93
diff -u -r1.93 NEWS
--- NEWS 21 Sep 2002 11:55:17 -0000 1.93
+++ NEWS 29 Sep 2002 18:08:05 -0000
@@ -3,6 +3,15 @@
*** Changes since GDB 5.3:
+* Default MI syntax changed to "mi2".
+
+The default MI (machine interface) syntax, selected with the command
+line option "-i=mi", has been changed to "mi2". The previous MI
+syntax can still be selected using "-i=mi1".
+
+Support for the original "mi0" syntax (included in GDB 5.0) has been
+removed.
+
* REMOVED configurations and files
V850EA ISA
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.127
diff -u -r1.127 gdb.texinfo
--- doc/gdb.texinfo 25 Sep 2002 22:55:30 -0000 1.127
+++ doc/gdb.texinfo 29 Sep 2002 18:08:19 -0000
@@ -1127,10 +1127,10 @@
program or device. This option is meant to be set by programs which
communicate with @value{GDBN} using it as a back end.
-@samp{--interpreter=mi} (or @samp{--interpreter=mi1}) causes
+@samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes
@value{GDBN} to use the @dfn{gdb/mi interface} (@pxref{GDB/MI, , The
@sc{gdb/mi} Interface}). The older @sc{gdb/mi} interface, included in
-@value{GDBN} version 5.0 can be selected with @samp{--interpreter=mi0}.
+@value{GDBN} version 5.3 can be selected with @samp{--interpreter=mi1}.
@item -write
@cindex @code{--write}
Index: mi/mi-main.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-main.c,v
retrieving revision 1.31
diff -u -r1.31 mi-main.c
--- mi/mi-main.c 11 Sep 2002 21:49:04 -0000 1.31
+++ mi/mi-main.c 29 Sep 2002 18:08:23 -0000
@@ -1514,15 +1514,15 @@
}
static void
-mi0_command_loop (void)
+mi1_command_loop (void)
{
- mi_command_loop (0);
+ mi_command_loop (1);
}
static void
-mi1_command_loop (void)
+mi2_command_loop (void)
{
- mi_command_loop (1);
+ mi_command_loop (2);
}
static void
@@ -1547,11 +1547,11 @@
return;
/* If we're _the_ interpreter, take control. */
- if (strcmp (interpreter_p, "mi0") == 0)
- command_loop_hook = mi0_command_loop;
- else if (strcmp (interpreter_p, "mi") == 0
- || strcmp (interpreter_p, "mi1") == 0)
+ if (strcmp (interpreter_p, "mi1") == 0)
command_loop_hook = mi1_command_loop;
+ else if (strcmp (interpreter_p, "mi") == 0
+ || strcmp (interpreter_p, "mi2") == 0)
+ command_loop_hook = mi2_command_loop;
else
return;
Index: mi/mi-out.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-out.c,v
retrieving revision 1.23
diff -u -r1.23 mi-out.c
--- mi/mi-out.c 19 Mar 2002 02:51:08 -0000 1.23
+++ mi/mi-out.c 29 Sep 2002 18:08:23 -0000
@@ -109,14 +109,6 @@
{
struct ui_out_data *data = ui_out_data (uiout);
mi_open (uiout, tblid, ui_out_type_tuple);
- if (data->mi_version == 0)
- {
- if (nr_rows == 0)
- data->suppress_output = 1;
- else
- mi_open (uiout, "hdr", ui_out_type_list);
- return;
- }
mi_field_int (uiout, -1/*fldno*/, -1/*width*/, -1/*alin*/,
"nr_rows", nr_rows);
mi_field_int (uiout, -1/*fldno*/, -1/*width*/, -1/*alin*/,
@@ -134,8 +126,6 @@
return;
/* close the table header line if there were any headers */
mi_close (uiout, ui_out_type_list);
- if (data->mi_version == 0)
- return;
mi_open (uiout, "body", ui_out_type_list);
}
@@ -146,11 +136,6 @@
{
struct ui_out_data *data = ui_out_data (uiout);
data->suppress_output = 0;
- if (data->mi_version == 0)
- {
- mi_close (uiout, ui_out_type_tuple);
- return;
- }
mi_close (uiout, ui_out_type_list); /* body */
mi_close (uiout, ui_out_type_tuple);
}
@@ -165,11 +150,6 @@
struct ui_out_data *data = ui_out_data (uiout);
if (data->suppress_output)
return;
- if (data->mi_version == 0)
- {
- mi_field_string (uiout, 0, width, alignment, 0, colhdr);
- return;
- }
mi_open (uiout, NULL, ui_out_type_tuple);
mi_field_int (uiout, 0, 0, 0, "width", width);
mi_field_int (uiout, 0, 0, 0, "alignment", alignment);
@@ -361,10 +341,7 @@
fputc_unfiltered ('{', data->buffer);
break;
case ui_out_type_list:
- if (data->mi_version == 0)
- fputc_unfiltered ('{', data->buffer);
- else
- fputc_unfiltered ('[', data->buffer);
+ fputc_unfiltered ('[', data->buffer);
break;
default:
internal_error (__FILE__, __LINE__, "bad switch");
@@ -382,10 +359,7 @@
fputc_unfiltered ('}', data->buffer);
break;
case ui_out_type_list:
- if (data->mi_version == 0)
- fputc_unfiltered ('}', data->buffer);
- else
- fputc_unfiltered (']', data->buffer);
+ fputc_unfiltered (']', data->buffer);
break;
default:
internal_error (__FILE__, __LINE__, "bad switch");
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-29 11:14 Andrew Cagney @ 2002-09-29 12:55 ` Daniel Jacobowitz 2002-09-29 13:19 ` Andrew Cagney 2002-09-29 22:01 ` Eli Zaretskii 2002-10-01 14:26 ` Andrew Cagney 2 siblings, 1 reply; 29+ messages in thread From: Daniel Jacobowitz @ 2002-09-29 12:55 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb-patches On Sun, Sep 29, 2002 at 02:14:45PM -0400, Andrew Cagney wrote: > Hello, > > The attached patch updates things so that "mi2" is the default MI > syntax. I need to add a mechanism so that the MI code can query the > version but I'll post that separatly. > > It modifies NEWS (comments?). > It updates the doco (ok?). > > Andrew It seems to me that this is going about everything backwards. There isn't an mi2 yet, is there? Only mi1 and some incompatible, proposed changes. Why are we making the default mi2 before we figure out what mi2 is? Not necessarily bad, but definitely unintuitive. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-29 12:55 ` Daniel Jacobowitz @ 2002-09-29 13:19 ` Andrew Cagney 2002-09-29 14:37 ` Daniel Jacobowitz 0 siblings, 1 reply; 29+ messages in thread From: Andrew Cagney @ 2002-09-29 13:19 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb-patches [-- Attachment #1: Type: text/plain, Size: 653 bytes --] > On Sun, Sep 29, 2002 at 02:14:45PM -0400, Andrew Cagney wrote: > >> Hello, >> >> The attached patch updates things so that "mi2" is the default MI >> syntax. I need to add a mechanism so that the MI code can query the >> version but I'll post that separatly. >> >> It modifies NEWS (comments?). >> It updates the doco (ok?). >> >> Andrew > > > It seems to me that this is going about everything backwards. > > There isn't an mi2 yet, is there? Actually, I think "mi2" changes have been sneeking through for a while. The attached, for instance, modifies [fixes] a commands output in a way that isn't backward compatible. enjoy, Andrew [-- Attachment #2: mailbox-message://ac131313@movemail/fsf/gdb/patches#23215 --] [-- Type: message/rfc822, Size: 45935 bytes --] [-- Attachment #2.1.1: Type: text/plain, Size: 761 bytes --] The attached patch changes the output format of the mi -var-update command to use a list for "changelist" rather than a single tuple. Approved? -- Jeff J. 2002-09-27 Jeff Johnston <jjohnstn@redhat.com> * mi/mi-cmd-var.c (mi_cmd_var_update): Fix for PR gdb/672. Output list begin and end for "changelist" rather than tuple begin/end. (varobj_update_one): Add tuple begin and end for varobj update output. * testsuite/gdb.mi/mi-var-block.exp: Change expected output from -var-update command to expect list format for "changelist". * testsuite/gdb.mi/mi-var-cmd.exp: Ditto. * testsuite/gdb.mi/mi-var-child: Ditto. * testsuite/gdb.mi/mi0-var-block.exp: Ditto. * testsuite/gdb.mi/mi0-var-cmd.exp: Ditto. * testsuite/gdb.mi/mi0-var-child.exp: Ditto. [-- Attachment #2.1.2: 672.patch --] [-- Type: text/plain, Size: 42195 bytes --] Index: mi/mi-cmd-var.c =================================================================== RCS file: /cvs/src/src/gdb/mi/mi-cmd-var.c,v retrieving revision 1.12 diff -u -r1.12 mi-cmd-var.c --- mi/mi-cmd-var.c 30 Jul 2002 13:45:15 -0000 1.12 +++ mi/mi-cmd-var.c 27 Sep 2002 22:14:26 -0000 @@ -419,10 +419,10 @@ if ((*name == '*') && (*(name + 1) == '\0')) { nv = varobj_list (&rootlist); - ui_out_tuple_begin (uiout, "changelist"); + ui_out_list_begin (uiout, "changelist"); if (nv <= 0) { - ui_out_tuple_end (uiout); + ui_out_list_end (uiout); return MI_CMD_DONE; } cr = rootlist; @@ -432,7 +432,7 @@ cr++; } xfree (rootlist); - ui_out_tuple_end (uiout); + ui_out_list_end (uiout); } else { @@ -441,9 +441,9 @@ if (var == NULL) error ("mi_cmd_var_update: Variable object not found"); - ui_out_tuple_begin (uiout, "changelist"); + ui_out_list_begin (uiout, "changelist"); varobj_update_one (var); - ui_out_tuple_end (uiout); + ui_out_list_end (uiout); } return MI_CMD_DONE; } @@ -469,17 +469,21 @@ return 1; else if (nc == -1) { + ui_out_tuple_begin (uiout, NULL); ui_out_field_string (uiout, "name", varobj_get_objname(var)); ui_out_field_string (uiout, "in_scope", "false"); + ui_out_tuple_end (uiout); return -1; } else if (nc == -2) { + ui_out_tuple_begin (uiout, NULL); ui_out_field_string (uiout, "name", varobj_get_objname (var)); ui_out_field_string (uiout, "in_scope", "true"); ui_out_field_string (uiout, "new_type", varobj_get_type(var)); ui_out_field_int (uiout, "new_num_children", varobj_get_num_children(var)); + ui_out_tuple_end (uiout); } else { @@ -487,9 +491,11 @@ cc = changelist; while (*cc != NULL) { + ui_out_tuple_begin (uiout, NULL); ui_out_field_string (uiout, "name", varobj_get_objname (*cc)); ui_out_field_string (uiout, "in_scope", "true"); ui_out_field_string (uiout, "type_changed", "false"); + ui_out_tuple_end (uiout); cc++; } xfree (changelist); Index: testsuite/gdb.mi/mi-var-block.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-var-block.exp,v retrieving revision 1.7 diff -u -r1.7 mi-var-block.exp --- testsuite/gdb.mi/mi-var-block.exp 17 Sep 2002 20:30:24 -0000 1.7 +++ testsuite/gdb.mi/mi-var-block.exp 27 Sep 2002 22:14:27 -0000 @@ -104,7 +104,7 @@ # Test: c_variable-3.4 # Desc: check foo, cb changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"foo\",in_scope=\"true\",type_changed=\"false\",name=\"cb\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"foo\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"cb\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars: cb foo changed" # step to "foo = 321;" @@ -155,7 +155,7 @@ clear_xfail *-*-* mi_gdb_test "-var-update foo" \ - "\\^done,changelist=\{\}" \ + "\\^done,changelist=\\\[\\\]" \ "update foo: did not change" mi_gdb_test "-var-delete inner_foo" \ @@ -193,7 +193,7 @@ # Desc: check that only cb is in scope (known gdb problem) setup_xfail *-*-* mi_gdb_test "-var-update foo2" \ - "\\^done,changelist=\{FIXME\}" \ + "\\^done,changelist=\\\[FIXME\\\]" \ "update foo2 should be out of scope: KNOWN PROBLEM" clear_xfail *-*-* setup_xfail *-*-* @@ -202,7 +202,7 @@ "update foo should be out of scope: KNOWN PROBLEM" clear_xfail *-*-* mi_gdb_test "-var-update cb" \ - "\\^done,changelist=\{\}" \ + "\\^done,changelist=\\\[\\\]" \ "update cb" # Test: c_variable-3.10 Index: testsuite/gdb.mi/mi-var-child.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-var-child.exp,v retrieving revision 1.11 diff -u -r1.11 mi-var-child.exp --- testsuite/gdb.mi/mi-var-child.exp 13 Sep 2002 21:29:42 -0000 1.11 +++ testsuite/gdb.mi/mi-var-child.exp 27 Sep 2002 22:14:27 -0000 @@ -750,7 +750,7 @@ # Test: c_variable-5.1 # Desc: check that nothing changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{\}" \ + "\\^done,changelist=\\\[\\\]" \ "update all vars. None changed" # Step over "struct_declarations.integer = 123;" @@ -760,7 +760,7 @@ # Test: c_variable-5.2 # Desc: check that integer changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.integer\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"struct_declarations.integer\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars struct_declarations.integer" # Step over: @@ -773,7 +773,7 @@ # Test: c_variable-5.3 # Desc: check that char_ptr changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"struct_declarations.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars struct_declarations.char_ptr" # Step over "struct_declarations.int_ptr_ptr = &foo;" @@ -783,7 +783,7 @@ # Test: c_variable-5.4 # Desc: check that int_ptr_ptr and children changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr.\\*\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr.\\*\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr.\\*\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr.\\*\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars int_ptr_ptr and children changed" # Step over "weird->long_array[0] = 1234;" @@ -793,7 +793,7 @@ # Test: c_variable-5.5 # Desc: check that long_array[0] changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.long_array.0\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"struct_declarations.long_array.0\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars struct_declarations.long_array.0 changed" # Step over "struct_declarations.long_array[1] = 2345;" @@ -803,7 +803,7 @@ # Test: c_variable-5.6 # Desc: check that long_array[1] changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.long_array.1\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"struct_declarations.long_array.1\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars struct_declarations.long_array.1 changed" # Step over "weird->long_array[2] = 3456;" @@ -813,7 +813,7 @@ # Test: c_variable-5.7 # Desc: check that long_array[2] changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.long_array.2\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"struct_declarations.long_array.2\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars struct_declarations.long_array.2 changed" # Step over: @@ -830,7 +830,7 @@ # Test: c_variable-5.8 # Desc: check that long_array[3-9] changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.long_array.3\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.4\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.5\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.6\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.7\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.8\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.9\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"struct_declarations.long_array.3\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.4\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.5\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.6\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.7\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.8\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.9\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars struct_declarations.long_array.3-9 changed" @@ -841,7 +841,7 @@ # Test: c_variable-5.9 # Desc: check that func_ptr changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.func_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"struct_declarations.func_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars struct_declarations.func_ptr changed" # Delete all variables @@ -1133,7 +1133,7 @@ # Test: c_variable-5.47 # Desc: check that psnp->char_ptr (and [0].char_ptr) changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"psnp->ptrs.0.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr.\\*\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr.\\*\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars psnp->char_ptr (and 0.char_ptr) changed" # Step over "snp1.char_ptr = &c3;" @@ -1143,7 +1143,7 @@ # Test: c_variable-5.48 # Desc: check that psnp->next->char_ptr (and [1].char_ptr) changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"psnp->ptrs.0.next.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr.\\*\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr.\\*\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars psnp->next->char_ptr (and 1.char_ptr) changed" @@ -1154,7 +1154,7 @@ # Test: c_variable-5.49 # Desc: check that psnp->next->next->char_ptr (and [2].char_ptr) changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"psnp->ptrs.0.next.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.next.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars psnp->next->next->char_ptr (and 2.char_ptr) changed" @@ -1165,7 +1165,7 @@ # Test: c_variable-5.50 # Desc: check that psnp->long_ptr (and [0].long_ptr) changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"psnp->ptrs.0.long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr.\\*\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr.\\*\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars psnp->long_ptr (and 0.long_ptr) changed" @@ -1178,7 +1178,7 @@ # Why does this have a FIXME? setup_xfail *-*-* mi_gdb_test "-var-update *" \ - "FIXME\\^done,changelist=\{name=\"psnp->ptrs.0.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "FIXME\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars psnp->next->long_ptr (and 1.long_ptr) changed" clear_xfail *-*-* @@ -1193,7 +1193,7 @@ # Test: c_variable-5.52 # Desc: check that psnp->next->next->long_ptr (and [2].long_ptr) changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"psnp->ptrs.0.next.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"psnp->ptrs.0.next.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars psnp->next->next->long_ptr (and 2.long_ptr) changed" Index: testsuite/gdb.mi/mi-var-cmd.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-var-cmd.exp,v retrieving revision 1.12 diff -u -r1.12 mi-var-cmd.exp --- testsuite/gdb.mi/mi-var-cmd.exp 17 Sep 2002 20:45:28 -0000 1.12 +++ testsuite/gdb.mi/mi-var-cmd.exp 27 Sep 2002 22:14:27 -0000 @@ -176,7 +176,7 @@ # Test: c_variable-2.1 # Desc: check whether values changed at do_block_tests mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{\}" \ + "\\^done,changelist=\\\[\\\]" \ "update all vars" # Step over "linteger = 1234;" @@ -185,7 +185,7 @@ # Test: c_variable-2.2 # Desc: check whether only linteger changed values mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars: linteger changed" # Step over "lpinteger = &linteger;" @@ -194,7 +194,7 @@ # Test: c_variable-2.3 # Desc: check whether only lpinteger changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"lpinteger\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"lpinteger\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars: lpinteger changed" # Step over "lcharacter = 'a';" @@ -203,7 +203,7 @@ # Test: c_variable-2.4 # Desc: check whether only lcharacter changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars: lcharacter changed" # Step over "lpcharacter = &lcharacter;" @@ -212,7 +212,7 @@ # Test: c_variable-2.5 # Desc: check whether only lpcharacter changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"lpcharacter\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"lpcharacter\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars: lpcharacter changed" @@ -234,7 +234,7 @@ # Desc: check whether llong, lplong, lfloat, lpfloat, ldouble, lpdouble, lsimple.integer, # lsimple.unsigned_character lsimple.integer lsimple.character changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\",name=\"lpdouble\",in_scope=\"true\",type_changed=\"false\",name=\"ldouble\",in_scope=\"true\",type_changed=\"false\",name=\"lpfloat\",in_scope=\"true\",type_changed=\"false\",name=\"lfloat\",in_scope=\"true\",type_changed=\"false\",name=\"lplong\",in_scope=\"true\",type_changed=\"false\",name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpdouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"ldouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lplong\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars: many changed" # Step over: @@ -249,7 +249,7 @@ # Test: c_variable-2.7 # Desc: check whether (lsimple.signed_character, lsimple.char_ptr) lpsimple, func changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"func\",in_scope=\"true\",type_changed=\"false\",name=\"lpsimple\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"func\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpsimple\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars: func and lpsimple changed" # Step over @@ -271,7 +271,7 @@ # Note: this test also checks that lpsimple->integer and lsimple.integer have # changed (they are the same) mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\",name=\"ldouble\",in_scope=\"true\",type_changed=\"false\",name=\"lfloat\",in_scope=\"true\",type_changed=\"false\",name=\"llong\",in_scope=\"true\",type_changed=\"false\",name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\",name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"ldouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars: func and lpsimple changed" @@ -421,7 +421,7 @@ # Test: c_variable-2.13 # Desc: change subroutine1 local i mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"i\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"i\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars: i changed" mi_step_to "subroutine1" "\{name=\"i\",value=\".*\"\},\{name=\"l\",value=\".*\"\}" \ @@ -430,7 +430,7 @@ # Test: c_variable-2.14 # Desc: change do_locals_tests local llong mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}\\\]" \ "update all vars: llong changed" mi_next_to "do_locals_tests" "" "var-cmd.c" "136" "next out of subroutine1" @@ -438,7 +438,7 @@ # Test: c_variable-2.15 # Desc: check for out of scope subroutine1 locals mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"l\",in_scope=\"false\",name=\"i\",in_scope=\"false\"\}" \ + "\\^done,changelist=\\\[\{name=\"l\",in_scope=\"false\"\},\{name=\"i\",in_scope=\"false\"\}\\\]" \ "update all vars: all now out of scope" # Done with locals/globals tests. Erase all variables @@ -538,15 +538,15 @@ mi_continue_to {.*} incr_a {.*} {.*var-cmd.c} {.*} {stop in incr_a} mi_gdb_test "-var-update selected_a" \ - {\^done,changelist=\{name="selected_a",in_scope="true",new_type="char",new_num_children="0"\}} \ - "update selected_a in incr_a" + "\\^done,changelist=\\\[\{name=\"selected_a\",in_scope=\"true\",new_type=\"char\",new_num_children=\"0\"\}\\\]" \ + "update selected_a in incr_a" mi_next "step a line in incr_a" mi_next "return from incr_a to do_special_tests" mi_gdb_test "-var-update selected_a" \ - {\^done,changelist=\{name="selected_a",in_scope="true",new_type="int",new_num_children="0"\}} \ - "update selected_a in do_special_tests" + "\\^done,changelist=\\\[\{name=\"selected_a\",in_scope=\"true\",new_type=\"int\",new_num_children=\"0\"\}\\\]" \ + "update selected_a in do_special_tests" mi_gdb_exit return 0 Index: testsuite/gdb.mi/mi0-var-block.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi0-var-block.exp,v retrieving revision 1.4 diff -u -r1.4 mi0-var-block.exp --- testsuite/gdb.mi/mi0-var-block.exp 19 Aug 2001 01:23:43 -0000 1.4 +++ testsuite/gdb.mi/mi0-var-block.exp 27 Sep 2002 22:14:27 -0000 @@ -104,7 +104,7 @@ # Test: c_variable-3.4 # Desc: check foo, cb changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"foo\",in_scope=\"true\",type_changed=\"false\",name=\"cb\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"foo\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"cb\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars: cb foo changed" # step to "foo = 321;" Index: testsuite/gdb.mi/mi0-var-child.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi0-var-child.exp,v retrieving revision 1.7 diff -u -r1.7 mi0-var-child.exp --- testsuite/gdb.mi/mi0-var-child.exp 17 Sep 2002 20:30:24 -0000 1.7 +++ testsuite/gdb.mi/mi0-var-child.exp 27 Sep 2002 22:14:27 -0000 @@ -787,7 +787,7 @@ # Test: c_variable-5.2 # Desc: check that integer changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.integer\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"struct_declarations.integer\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars struct_declarations.integer" # Step over: @@ -808,7 +808,7 @@ # Test: c_variable-5.3 # Desc: check that char_ptr changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"struct_declarations.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars struct_declarations.char_ptr" # Step over "struct_declarations.int_ptr_ptr = &foo;" @@ -825,7 +825,7 @@ # Test: c_variable-5.4 # Desc: check that int_ptr_ptr and children changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr.\\*\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr.\\*\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"weird->int_ptr_ptr.\\*weird->int_ptr_ptr.\\*\\*weird->int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.int_ptr_ptr.\\*int_ptr_ptr.\\*\\*int_ptr_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars int_ptr_ptr and children changed" # Step over "weird->long_array[0] = 1234;" @@ -842,7 +842,7 @@ # Test: c_variable-5.5 # Desc: check that long_array[0] changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.long_array.0\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"struct_declarations.long_array.0\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars struct_declarations.long_array.0 changed" # Step over "struct_declarations.long_array[1] = 2345;" @@ -859,7 +859,7 @@ # Test: c_variable-5.6 # Desc: check that long_array[1] changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.long_array.1\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"struct_declarations.long_array.1\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars struct_declarations.long_array.1 changed" # Step over "weird->long_array[2] = 3456;" @@ -876,7 +876,7 @@ # Test: c_variable-5.7 # Desc: check that long_array[2] changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.long_array.2\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"struct_declarations.long_array.2\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars struct_declarations.long_array.2 changed" # Step over: @@ -900,7 +900,7 @@ # Test: c_variable-5.8 # Desc: check that long_array[3-9] changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.long_array.3\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.4\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.5\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.6\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.7\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.8\",in_scope=\"true\",type_changed=\"false\",name=\"struct_declarations.long_array.9\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"struct_declarations.long_array.3\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.4\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.5\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.6\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.7\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.8\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"struct_declarations.long_array.9\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars struct_declarations.long_array.3-9 changed" @@ -918,7 +918,7 @@ # Test: c_variable-5.9 # Desc: check that func_ptr changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"struct_declarations.func_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"struct_declarations.func_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars struct_declarations.func_ptr changed" # Delete all variables @@ -1224,7 +1224,7 @@ # Test: c_variable-5.47 # Desc: check that psnp->char_ptr (and [0].char_ptr) changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"psnp->ptrs.0.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr.\\*\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"psnp->ptrs.0.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->char_ptr.\\*psnp->char_ptr.\\*\\*psnp->char_ptr.\\*\\*\\*psnp->char_ptr.\\*\\*\\*\\*psnp->char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars psnp->char_ptr (and 0.char_ptr) changed" # Step over "snp1.char_ptr = &c3;" @@ -1242,7 +1242,7 @@ # Test: c_variable-5.48 # Desc: check that psnp->next->char_ptr (and [1].char_ptr) changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"psnp->ptrs.0.next.char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr.\\*\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"psnp->ptrs.0.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->ptrs.0.next.char_ptr.\\*char_ptr.\\*\\*char_ptr.\\*\\*\\*char_ptr.\\*\\*\\*\\*char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars psnp->next->char_ptr (and 1.char_ptr) changed" @@ -1261,7 +1261,7 @@ # Test: c_variable-5.49 # Desc: check that psnp->next->next->char_ptr (and [2].char_ptr) changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"psnp->ptrs.0.next.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"psnp->ptrs.0.next.next.char_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars psnp->next->next->char_ptr (and 2.char_ptr) changed" @@ -1279,7 +1279,7 @@ # Test: c_variable-5.50 # Desc: check that psnp->long_ptr (and [0].long_ptr) changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"psnp->ptrs.0.long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\",name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr.\\*\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"psnp->ptrs.0.long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"psnp->long_ptr.\\*psnp->long_ptr.\\*\\*psnp->long_ptr.\\*\\*\\*psnp->long_ptr.\\*\\*\\*\\*psnp->long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars psnp->long_ptr (and 0.long_ptr) changed" @@ -1300,7 +1300,7 @@ # Why does this have a FIXME? setup_xfail *-*-* mi_gdb_test "-var-update *" \ - "FIXME\\^done,changelist=\{name=\"psnp->ptrs.0.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "FIXME\\^done,changelist=\{\{name=\"psnp->ptrs.0.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars psnp->next->long_ptr (and 1.long_ptr) changed" clear_xfail *-*-* @@ -1323,7 +1323,7 @@ # Test: c_variable-5.52 # Desc: check that psnp->next->next->long_ptr (and [2].long_ptr) changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"psnp->ptrs.0.next.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"psnp->ptrs.0.next.next.long_ptr\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars psnp->next->next->long_ptr (and 2.long_ptr) changed" Index: testsuite/gdb.mi/mi0-var-cmd.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi0-var-cmd.exp,v retrieving revision 1.9 diff -u -r1.9 mi0-var-cmd.exp --- testsuite/gdb.mi/mi0-var-cmd.exp 17 Sep 2002 20:30:24 -0000 1.9 +++ testsuite/gdb.mi/mi0-var-cmd.exp 27 Sep 2002 22:14:27 -0000 @@ -185,7 +185,7 @@ # Test: c_variable-2.2 # Desc: check whether only linteger changed values mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars: linteger changed" # Step over "lpinteger = &linteger;" @@ -194,7 +194,7 @@ # Test: c_variable-2.3 # Desc: check whether only lpinteger changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"lpinteger\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"lpinteger\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars: lpinteger changed" # Step over "lcharacter = 'a';" @@ -203,7 +203,7 @@ # Test: c_variable-2.4 # Desc: check whether only lcharacter changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars: lcharacter changed" # Step over "lpcharacter = &lcharacter;" @@ -212,7 +212,7 @@ # Test: c_variable-2.5 # Desc: check whether only lpcharacter changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"lpcharacter\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"lpcharacter\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars: lpcharacter changed" @@ -234,7 +234,7 @@ # Desc: check whether llong, lplong, lfloat, lpfloat, ldouble, lpdouble, lsimple.integer, # lsimple.unsigned_character lsimple.integer lsimple.character changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\",name=\"lpdouble\",in_scope=\"true\",type_changed=\"false\",name=\"ldouble\",in_scope=\"true\",type_changed=\"false\",name=\"lpfloat\",in_scope=\"true\",type_changed=\"false\",name=\"lfloat\",in_scope=\"true\",type_changed=\"false\",name=\"lplong\",in_scope=\"true\",type_changed=\"false\",name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpdouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"ldouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lplong\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars: many changed" # Step over: @@ -249,7 +249,7 @@ # Test: c_variable-2.7 # Desc: check whether (lsimple.signed_character, lsimple.char_ptr) lpsimple, func changed mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"func\",in_scope=\"true\",type_changed=\"false\",name=\"lpsimple\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"func\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lpsimple\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars: func and lpsimple changed" # Step over @@ -271,7 +271,7 @@ # Note: this test also checks that lpsimple->integer and lsimple.integer have # changed (they are the same) mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\",name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\",name=\"ldouble\",in_scope=\"true\",type_changed=\"false\",name=\"lfloat\",in_scope=\"true\",type_changed=\"false\",name=\"llong\",in_scope=\"true\",type_changed=\"false\",name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\",name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"lsimple.integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple->integer\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lsimple.character\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"ldouble\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lfloat\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"lcharacter\",in_scope=\"true\",type_changed=\"false\"\},\{name=\"linteger\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars: func and lpsimple changed" @@ -421,7 +421,7 @@ # Test: c_variable-2.13 # Desc: change subroutine1 local i mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"i\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"i\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars: i changed" mi0_step_to "subroutine1" "\{name=\"i\",value=\".*\"\},\{name=\"l\",value=\".*\"\}" \ @@ -430,7 +430,7 @@ # Test: c_variable-2.14 # Desc: change do_locals_tests local llong mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"llong\",in_scope=\"true\",type_changed=\"false\"\}\}" \ "update all vars: llong changed" mi0_next_to "do_locals_tests" "" "var-cmd.c" "136" "next out of subroutine1" @@ -438,7 +438,7 @@ # Test: c_variable-2.15 # Desc: check for out of scope subroutine1 locals mi_gdb_test "-var-update *" \ - "\\^done,changelist=\{name=\"l\",in_scope=\"false\",name=\"i\",in_scope=\"false\"\}" \ + "\\^done,changelist=\{\{name=\"l\",in_scope=\"false\"\},\{name=\"i\",in_scope=\"false\"\}\}" \ "update all vars: all now out of scope" # Done with locals/globals tests. Erase all variables ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-29 13:19 ` Andrew Cagney @ 2002-09-29 14:37 ` Daniel Jacobowitz 2002-09-29 14:46 ` Andrew Cagney 0 siblings, 1 reply; 29+ messages in thread From: Daniel Jacobowitz @ 2002-09-29 14:37 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb-patches On Sun, Sep 29, 2002 at 04:19:11PM -0400, Andrew Cagney wrote: > >On Sun, Sep 29, 2002 at 02:14:45PM -0400, Andrew Cagney wrote: > > > >>Hello, > >> > >>The attached patch updates things so that "mi2" is the default MI > >>syntax. I need to add a mechanism so that the MI code can query the > >>version but I'll post that separatly. > >> > >>It modifies NEWS (comments?). > >>It updates the doco (ok?). > >> > >>Andrew > > > > > >It seems to me that this is going about everything backwards. > > > >There isn't an mi2 yet, is there? > > Actually, I think "mi2" changes have been sneeking through for a while. > The attached, for instance, modifies [fixes] a commands output in a > way that isn't backward compatible. Are you planning to revert mi1 then? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-29 14:37 ` Daniel Jacobowitz @ 2002-09-29 14:46 ` Andrew Cagney 2002-09-29 21:55 ` Daniel Jacobowitz 0 siblings, 1 reply; 29+ messages in thread From: Andrew Cagney @ 2002-09-29 14:46 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb-patches > On Sun, Sep 29, 2002 at 04:19:11PM -0400, Andrew Cagney wrote: > >> >On Sun, Sep 29, 2002 at 02:14:45PM -0400, Andrew Cagney wrote: >> > > >> >>Hello, >> >> >> >>The attached patch updates things so that "mi2" is the default MI >> >>syntax. I need to add a mechanism so that the MI code can query the >> >>version but I'll post that separatly. >> >> >> >>It modifies NEWS (comments?). >> >>It updates the doco (ok?). >> >> >> >>Andrew > >> > >> > >> >It seems to me that this is going about everything backwards. >> > >> >There isn't an mi2 yet, is there? > >> >> Actually, I think "mi2" changes have been sneeking through for a while. >> The attached, for instance, modifies [fixes] a commands output in a >> way that isn't backward compatible. > > > Are you planning to revert mi1 then? Que? Andrew ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-29 14:46 ` Andrew Cagney @ 2002-09-29 21:55 ` Daniel Jacobowitz 2002-09-30 8:03 ` Andrew Cagney 0 siblings, 1 reply; 29+ messages in thread From: Daniel Jacobowitz @ 2002-09-29 21:55 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb-patches On Sun, Sep 29, 2002 at 05:46:06PM -0400, Andrew Cagney wrote: > >On Sun, Sep 29, 2002 at 04:19:11PM -0400, Andrew Cagney wrote: > > > >>>On Sun, Sep 29, 2002 at 02:14:45PM -0400, Andrew Cagney wrote: > >>> > > > >>>>Hello, > >>>> > >>>>The attached patch updates things so that "mi2" is the default MI > >>>>syntax. I need to add a mechanism so that the MI code can query the > >>>>version but I'll post that separatly. > >>>> > >>>>It modifies NEWS (comments?). > >>>>It updates the doco (ok?). > >>>> > >>>>Andrew > > > >>> > >>> > >>>It seems to me that this is going about everything backwards. > >>> > >>>There isn't an mi2 yet, is there? > > > >> > >>Actually, I think "mi2" changes have been sneeking through for a while. > >> The attached, for instance, modifies [fixes] a commands output in a > >>way that isn't backward compatible. > > > > > >Are you planning to revert mi1 then? > > Que? "mi2" changes have been sneaking in. Are you planning to revert them - create an "mi1" which matches what mi1 actually was. Otherwise, where is the line drawn to mark the interface version as final? It seems to me that the default shouldn't be evolving, that -i=mi should default to a fixed point until the next version is running. Maybe I'm wrong though. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-29 21:55 ` Daniel Jacobowitz @ 2002-09-30 8:03 ` Andrew Cagney 2002-09-30 8:16 ` Daniel Jacobowitz 0 siblings, 1 reply; 29+ messages in thread From: Andrew Cagney @ 2002-09-30 8:03 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb-patches >> > >> >Are you planning to revert mi1 then? > >> >> Que? > > > "mi2" changes have been sneaking in. Are you planning to revert them - > create an "mi1" which matches what mi1 actually was. It's a bit late for that. Someone should audit the changes made so far and identify which caused syntax changes and update accordingly. Fixes could, perhaphs be pushed into 5.3 (but I don't have the time). > Otherwise, where is the line drawn to mark the interface version as > final? It seems to me that the default shouldn't be evolving, that > -i=mi should default to a fixed point until the next version is > running. I think a line is drawn when each release is made. I'd expect an MI client to explicitly specify -i=miN (where N was formally released) rather than trust -i=mi. However, should the HEAD hold off on recognizing -i=mi2 until the next branch is cut? On the HEAD, -i=mi evolves by definition. However, -i=mi2 is evolving as well :-( Andrew ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-30 8:03 ` Andrew Cagney @ 2002-09-30 8:16 ` Daniel Jacobowitz 2002-09-30 15:06 ` Andrew Cagney 0 siblings, 1 reply; 29+ messages in thread From: Daniel Jacobowitz @ 2002-09-30 8:16 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb-patches On Mon, Sep 30, 2002 at 11:03:55AM -0400, Andrew Cagney wrote: > > >>> > >>>Are you planning to revert mi1 then? > > > >> > >>Que? > > > > > >"mi2" changes have been sneaking in. Are you planning to revert them - > >create an "mi1" which matches what mi1 actually was. > > It's a bit late for that. Someone should audit the changes made so far > and identify which caused syntax changes and update accordingly. Fixes > could, perhaphs be pushed into 5.3 (but I don't have the time). > > >Otherwise, where is the line drawn to mark the interface version as > >final? It seems to me that the default shouldn't be evolving, that > >-i=mi should default to a fixed point until the next version is > >running. > > I think a line is drawn when each release is made. I'd expect an MI > client to explicitly specify -i=miN (where N was formally released) > rather than trust -i=mi. > > However, should the HEAD hold off on recognizing -i=mi2 until the next > branch is cut? On the HEAD, -i=mi evolves by definition. However, > -i=mi2 is evolving as well :-( That'd be best I think. I think that -i=mi2 specifies a fixed standard and we don't have one yet; so how about -i=mi being different from -i=mi1, but not adding -i=mi2 until we're ready to fix the interface? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-30 8:16 ` Daniel Jacobowitz @ 2002-09-30 15:06 ` Andrew Cagney 2002-09-30 15:36 ` Daniel Jacobowitz 0 siblings, 1 reply; 29+ messages in thread From: Andrew Cagney @ 2002-09-30 15:06 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb-patches >> However, should the HEAD hold off on recognizing -i=mi2 until the next >> branch is cut? On the HEAD, -i=mi evolves by definition. However, >> -i=mi2 is evolving as well :-( > > > That'd be best I think. I think that -i=mi2 specifies a fixed standard > and we don't have one yet; so how about -i=mi being different from > -i=mi1, but not adding -i=mi2 until we're ready to fix the interface? I just looked, and I take the idea back. It means updating NEWS, DOC and testsuite twice - just after the branch (to start the new interface) and just before a branch (to freeze the new interface). I think its going to be easier to get it all done once just after the branch. If someone reports a bug against a YYYYMMDD version of GDB then it's pretty clear that they are not using a released GDB. Andrew ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-30 15:06 ` Andrew Cagney @ 2002-09-30 15:36 ` Daniel Jacobowitz 0 siblings, 0 replies; 29+ messages in thread From: Daniel Jacobowitz @ 2002-09-30 15:36 UTC (permalink / raw) To: gdb-patches On Mon, Sep 30, 2002 at 06:06:34PM -0400, Andrew Cagney wrote: > > >>However, should the HEAD hold off on recognizing -i=mi2 until the next > >>branch is cut? On the HEAD, -i=mi evolves by definition. However, > >>-i=mi2 is evolving as well :-( > > > > > >That'd be best I think. I think that -i=mi2 specifies a fixed standard > >and we don't have one yet; so how about -i=mi being different from > >-i=mi1, but not adding -i=mi2 until we're ready to fix the interface? > > I just looked, and I take the idea back. It means updating NEWS, DOC > and testsuite twice - just after the branch (to start the new interface) > and just before a branch (to freeze the new interface). > > I think its going to be easier to get it all done once just after the > branch. If someone reports a bug against a YYYYMMDD version of GDB then > it's pretty clear that they are not using a released GDB. OK. My logic went like: It would be nice to be able to use a snapshot, which has non-MI-syntax-related improvements and fixes in it, without having to handle a changing interface. But we can already do that: they use -i=mi1. So it's all good. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-29 11:14 Andrew Cagney 2002-09-29 12:55 ` Daniel Jacobowitz @ 2002-09-29 22:01 ` Eli Zaretskii 2002-09-30 15:14 ` Andrew Cagney 2002-10-01 14:26 ` Andrew Cagney 2 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2002-09-29 22:01 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb-patches On Sun, 29 Sep 2002, Andrew Cagney wrote: > It modifies NEWS (comments?). Fine with me. > It updates the doco (ok?). Yes, but perhaps the manual should also say that mi0 is no longer supported. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-29 22:01 ` Eli Zaretskii @ 2002-09-30 15:14 ` Andrew Cagney 2002-09-30 22:13 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Andrew Cagney @ 2002-09-30 15:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb-patches > On Sun, 29 Sep 2002, Andrew Cagney wrote: > > >> It modifies NEWS (comments?). > > > Fine with me. > > >> It updates the doco (ok?). > > > Yes, but perhaps the manual should also say that mi0 is no longer > supported. Now is: @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes @value{GDBN} to use the current @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, , The @sc{gdb/mi} Interface}). The previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3, can be selected with @samp{--interpreter=mi1}. Earlier @sc{gdb/mi} interfaces are not supported. Andrew ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-30 15:14 ` Andrew Cagney @ 2002-09-30 22:13 ` Eli Zaretskii 0 siblings, 0 replies; 29+ messages in thread From: Eli Zaretskii @ 2002-09-30 22:13 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb-patches On Mon, 30 Sep 2002, Andrew Cagney wrote: > > Yes, but perhaps the manual should also say that mi0 is no longer > > supported. > > Now is: > > @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes > @value{GDBN} to use the current @dfn{@sc{gdb/mi} interface} > (@pxref{GDB/MI, , The @sc{gdb/mi} Interface}). The previous @sc{gdb/mi} > interface, included in @value{GDBN} version 5.3, can be selected with > @samp{--interpreter=mi1}. Earlier @sc{gdb/mi} interfaces > are not supported. Fine, thanks. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 2002-09-29 11:14 Andrew Cagney 2002-09-29 12:55 ` Daniel Jacobowitz 2002-09-29 22:01 ` Eli Zaretskii @ 2002-10-01 14:26 ` Andrew Cagney 2 siblings, 0 replies; 29+ messages in thread From: Andrew Cagney @ 2002-10-01 14:26 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb-patches Just FYI, I've checked in the attatched. Unless it's in it isn't possible to test that an MI change works with the new mi2 syntax but doesn't break the mi1 syntax. It still leaves unresolved, the issue of when mi2 should be frozen. Andrew > Index: ChangeLog > 2002-09-29 Andrew Cagney <ac131313@redhat.com> > > * NEWS: Mention that MI syntax changed to "mi2" and that "mi0" > syntax has been removed. > > Index: doc/ChangeLog > 2002-09-29 Andrew Cagney <ac131313@redhat.com> > > * gdb.texinfo (Mode Options): Update --interpreter option. "mi2" > and "mi1" instead of "mi1" and "mi0". > > Index: mi/ChangeLog > 2002-09-29 Andrew Cagney <ac131313@redhat.com> > > * mi-main.c (mi2_command_loop): New function. > (mi0_command_loop): Delete function. > (_initialize_mi_main): Recognize, and default to, "mi2". Do not > recognize "mi0". > * mi-out.c (mi_table_begin): Remove mi0 code. > (mi_table_body, mi_table_end): Ditto. > (mi_table_header, mi_open, mi_close): Ditto. > ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2002-10-26 1:22 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1035593825.16489.ezmlm@sources.redhat.com>
2002-10-25 18:22 ` [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 Jim Ingham
[not found] <1033404264.17743.ezmlm@sources.redhat.com>
2002-09-30 17:48 ` Jim Ingham
2002-10-01 9:29 ` Andrew Cagney
2002-10-01 10:34 ` Jim Ingham
2002-10-01 13:25 ` Andrew Cagney
2002-10-01 14:01 ` Jim Ingham
2002-10-01 15:10 ` Andrew Cagney
2002-10-01 15:46 ` Jim Ingham
2002-10-01 16:39 ` Keith Seitz
2002-10-01 17:45 ` Jim Ingham
2002-10-02 7:58 ` Keith Seitz
2002-10-02 10:49 ` Jim Ingham
2002-10-25 14:48 ` Andrew Cagney
2002-10-01 23:25 ` Jason Molenda
2002-10-02 10:22 ` Stan Shebs
2002-09-29 11:14 Andrew Cagney
2002-09-29 12:55 ` Daniel Jacobowitz
2002-09-29 13:19 ` Andrew Cagney
2002-09-29 14:37 ` Daniel Jacobowitz
2002-09-29 14:46 ` Andrew Cagney
2002-09-29 21:55 ` Daniel Jacobowitz
2002-09-30 8:03 ` Andrew Cagney
2002-09-30 8:16 ` Daniel Jacobowitz
2002-09-30 15:06 ` Andrew Cagney
2002-09-30 15:36 ` Daniel Jacobowitz
2002-09-29 22:01 ` Eli Zaretskii
2002-09-30 15:14 ` Andrew Cagney
2002-09-30 22:13 ` Eli Zaretskii
2002-10-01 14:26 ` Andrew Cagney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox