* Bob's MI objective @ 2004-10-06 20:13 Andrew Cagney 2004-10-06 22:36 ` Bob Rossi 0 siblings, 1 reply; 21+ messages in thread From: Andrew Cagney @ 2004-10-06 20:13 UTC (permalink / raw) To: gdb, Bob Rossi Bob, what's your overall objective here? Perhaphs our lack of appreciation of your overriding goals is the reason that some (at least I) are feeling somewhat puzzled and confused. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-06 20:13 Bob's MI objective Andrew Cagney @ 2004-10-06 22:36 ` Bob Rossi 2004-10-07 2:40 ` Andrew Cagney 2004-10-08 7:17 ` Bob Rossi 0 siblings, 2 replies; 21+ messages in thread From: Bob Rossi @ 2004-10-06 22:36 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb On Wed, Oct 06, 2004 at 04:12:32PM -0400, Andrew Cagney wrote: > Bob, what's your overall objective here? Perhaphs our lack of > appreciation of your overriding goals is the reason that some (at least > I) are feeling somewhat puzzled and confused. I want an MI version named after myself, specifically 'gdb -i=bobmi' No seriously, I already have a front end that works off of GDB's annotate two feature. I understand that the annotate two interface could be removed from GDB. I asked you a year or two ago to wait until MI is capable of replacing the annotations. I personally wrote the two commands to MI -file-list-exec-source-file -file-list-exec-source-files that make MI capable of replacing the annotations interface for front ends that do not already know what files are involved in the users applications. I appreciate your patience in this matter. I feel that I have done my part in this matter to prove to you that I am interested and involved with the MI interface evolving for small front ends. Now I am beginning to add the MI interface to my front end. I spent the last few weeks looking at the grammar of the currently documented MI output syntax. The documentation is incorrect, but mostly correct and I suggested some changes to it so that others could benefit. I have come up with the rules and generated a parser that is capable of parsing an MI output command. I would like to validate the output of GDB's MI commands in the testsuite to prove to us all that every MI command obeys the protocol. This is something I am interested in doing for the benefit of all front end developers. Not just myself. Now, my next objective is to figure these things, * I would like to know what GDB's policy is in regards to supporting old MI protocols. ( I have received several opposing views on this ) * I would like to ensure that my front end works well with snapshots of GDB. I do not want to work with the MI development protocol, I just want to work with the last officially supported protocol. * I would like to make sure that development protocols are never used by my front end and that I can figure out all of the officially supported MI protocols that a given GDB supports. By being able to understand the highest officially supported protocol that both GDB and my front end understand is critical to me. I think it is safe to say that a front end needs to know the MI protocols that a given GDB supports. The way we get that info from GDB to the front end is the question in debate. Thanks, Bob Rossi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-06 22:36 ` Bob Rossi @ 2004-10-07 2:40 ` Andrew Cagney 2004-10-07 17:20 ` Bob Rossi 2004-10-08 7:17 ` Bob Rossi 1 sibling, 1 reply; 21+ messages in thread From: Andrew Cagney @ 2004-10-07 2:40 UTC (permalink / raw) To: Bob Rossi; +Cc: gdb > * I would like to know what GDB's policy is in regards to supporting old > MI protocols. ( I have received several opposing views on this ) By "supported" you're expecting? I've stated what people developing GDB test, and given you a pretty clear hint as to the consequence. I was wondering more of what your project and its goals were. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-07 2:40 ` Andrew Cagney @ 2004-10-07 17:20 ` Bob Rossi 2004-10-07 20:50 ` Andrew Cagney 0 siblings, 1 reply; 21+ messages in thread From: Bob Rossi @ 2004-10-07 17:20 UTC (permalink / raw) To: Andrew Cagney, g; +Cc: gdb On Wed, Oct 06, 2004 at 06:36:02PM -0400, Andrew Cagney wrote: > > * I would like to know what GDB's policy is in regards to supporting old > > MI protocols. ( I have received several opposing views on this ) > > By "supported" you're expecting? I've stated what people developing GDB > test, and given you a pretty clear hint as to the consequence. Understood, here is what I am hoping for at a minimum. * GDB supports at least 1 MI protocol for an official release. Supporting multiple MI protocols would be better for me, but not a requirement. If GDB could support multiple protocols it would improve the chances of a given front end working with a given GDB. * GDB supports at least 1 MI protocol for a CVS snapshot. The development MI protocol is probably not suitable for front ends to work with, until it has stabilized and become official. So I am hoping that GDB supports the last officially supported MI protocol during it's development process, until the development protocol is ready to become stable. > I was wondering more of what your project and its goals were. CGDB is the front end I am working on, that said, I am actually not doing all of the development of CGDB, just some of it. I am focusing more on libtgdb. This is basically a library that is capable of communicating with GDB with any interface that GDB supports. It already supports annotate 2, now I am adding support for MI2. I would like to make this library support annotate 2, MI2, MI3, ... Any front end developer can than take this library, and use it for there front end, thus removing the burden of communicating with GDB. In essence it is a libgdb that works with any GDB, not just one. The library will be light weight, to the point where it can be used for many applications, not just front ends ( embedded into tools that need simple functionality like backtrace's, ... ). I am interested in making this library part of the GDB distro, but wouldn't suggest such a thing until it works. I think it would be good if GDB distributed not only the MI interface and doco, but a reference implementation of dealing with the protocols. All of this said, I have a goal of making MI work and make sure that the MI output commands actually adhere to the MI output syntax by testing this in the testsuite. Probably the next step would be to make sure that the MI input syntax follows the same rules. However, I have not made it that far. Do these goals seem reasonable? Thanks, Bob Rossi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-07 17:20 ` Bob Rossi @ 2004-10-07 20:50 ` Andrew Cagney 2004-10-07 22:42 ` Bob Rossi 0 siblings, 1 reply; 21+ messages in thread From: Andrew Cagney @ 2004-10-07 20:50 UTC (permalink / raw) To: Bob Rossi; +Cc: gdb > On Wed, Oct 06, 2004 at 06:36:02PM -0400, Andrew Cagney wrote: > >>>> > * I would like to know what GDB's policy is in regards to supporting old >>>> > MI protocols. ( I have received several opposing views on this ) >> >>> >>> By "supported" you're expecting? I've stated what people developing GDB >>> test, and given you a pretty clear hint as to the consequence. > > > Understood, here is what I am hoping for at a minimum. > > * GDB supports at least 1 MI protocol for an official release. > Supporting multiple MI protocols would be better for me, but > not a requirement. If GDB could support multiple protocols it > would improve the chances of a given front end working with a > given GDB. But by "support" what do you mean - even a dictionary definition. GDB includes at least one MI implementation, but that says nothing about how well it is either implemented or supported. > * GDB supports at least 1 MI protocol for a CVS snapshot. The > development MI protocol is probably not suitable for front ends > to work with, until it has stabilized and become official. So I am > hoping that GDB supports the last officially supported MI protocol > during it's development process, until the development protocol is > ready to become stable. > > >>> I was wondering more of what your project and its goals were. > > > CGDB is the front end I am working on, that said, I am actually not > doing all of the development of CGDB, just some of it. > > I am focusing more on libtgdb. This is basically a library that is > capable of communicating with GDB with any interface that GDB supports. Why not instead help with libgdb, and the problem of being able to directly link in the debugger? > It already supports annotate 2, now I am adding support for MI2. I would > like to make this library support annotate 2, MI2, MI3, ... > > Any front end developer can than take this library, and use it for there > front end, thus removing the burden of communicating with GDB. In > essence it is a libgdb that works with any GDB, not just one. The > library will be light weight, to the point where it can be used for many > applications, not just front ends ( embedded into tools that need simple > functionality like backtrace's, ... ). > > I am interested in making this library part of the GDB distro, but > wouldn't suggest such a thing until it works. I think it would be good > if GDB distributed not only the MI interface and doco, but a reference > implementation of dealing with the protocols. > > All of this said, I have a goal of making MI work and make sure that the > MI output commands actually adhere to the MI output syntax by testing > this in the testsuite. Probably the next step would be to make sure that > the MI input syntax follows the same rules. However, I have not made it > that far. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-07 20:50 ` Andrew Cagney @ 2004-10-07 22:42 ` Bob Rossi 2004-10-08 8:40 ` Fabian Cenedese 0 siblings, 1 reply; 21+ messages in thread From: Bob Rossi @ 2004-10-07 22:42 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb On Thu, Oct 07, 2004 at 03:17:45PM -0400, Andrew Cagney wrote: > >On Wed, Oct 06, 2004 at 06:36:02PM -0400, Andrew Cagney wrote: > > > >>>>> * I would like to know what GDB's policy is in regards to > >>>>supporting old > >>>>> MI protocols. ( I have received several opposing views on this ) > >> > >>> > >>>By "supported" you're expecting? I've stated what people developing GDB > >>>test, and given you a pretty clear hint as to the consequence. > > > > > >Understood, here is what I am hoping for at a minimum. > > > > * GDB supports at least 1 MI protocol for an official release. > > Supporting multiple MI protocols would be better for me, but > > not a requirement. If GDB could support multiple protocols it > > would improve the chances of a given front end working with a > > given GDB. > > But by "support" what do you mean - even a dictionary definition. GDB > includes at least one MI implementation, but that says nothing about how > well it is either implemented or supported. That's a good question. Well, by support I simply mean, GDB is officially saying that a particular MI protocol is implemented as it should be, that it is tested to make sure that it works to the best of the GDB developers knowledge and that it is safe to use by front ends. I am assuming that MI protocols in development ( right after a version bump, but before a major release ) is considered unsupported. By this I guess I mean that it should not be used by front ends until it is stable. Maybe a better word for "support" in this context is "stable". > > * GDB supports at least 1 MI protocol for a CVS snapshot. The > > development MI protocol is probably not suitable for front ends > > to work with, until it has stabilized and become official. So I am > > hoping that GDB supports the last officially supported MI protocol > > during it's development process, until the development protocol is > > ready to become stable. > > > > > >>>I was wondering more of what your project and its goals were. > > > > > >CGDB is the front end I am working on, that said, I am actually not > >doing all of the development of CGDB, just some of it. > > > >I am focusing more on libtgdb. This is basically a library that is > >capable of communicating with GDB with any interface that GDB supports. > > Why not instead help with libgdb, and the problem of being able to > directly link in the debugger? What implementation approach is libgdb taking? Does it expect the front end to link directly to it, so that a front end is tied to a particular version of GDB? I like the idea of a libgdb that is capable of communicating with any version of GDB that talks a valid MI protocol. This makes the library more flexible. I guess this is essentially the goal I am working towards with libtgdb. Bob Rossi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-07 22:42 ` Bob Rossi @ 2004-10-08 8:40 ` Fabian Cenedese 2004-10-08 13:17 ` Bob Rossi 0 siblings, 1 reply; 21+ messages in thread From: Fabian Cenedese @ 2004-10-08 8:40 UTC (permalink / raw) To: gdb >> >Understood, here is what I am hoping for at a minimum. >> > >> > * GDB supports at least 1 MI protocol for an official release. >> > Supporting multiple MI protocols would be better for me, but >> > not a requirement. If GDB could support multiple protocols it >> > would improve the chances of a given front end working with a >> > given GDB. >> >> But by "support" what do you mean - even a dictionary definition. GDB >> includes at least one MI implementation, but that says nothing about how >> well it is either implemented or supported. > >That's a good question. > >Well, by support I simply mean, GDB is officially saying that a >particular MI protocol is implemented as it should be, that it is tested >to make sure that it works to the best of the GDB developers knowledge and >that it is safe to use by front ends. > >I am assuming that MI protocols in development ( right after a version >bump, but before a major release ) is considered unsupported. By this I >guess I mean that it should not be used by front ends until it is >stable. Maybe a better word for "support" in this context is "stable". I think the implementation grade is quite important. Though mi2 is considered now the official and stable mi version I find that half of it is unimplemented which makes it somehow useless for me. From this point of view I'd say mi2 is the development version. (And yes, I'm not only complaining, I have started implementing some of the missing mi functions.) Thanks bye Fabi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-08 8:40 ` Fabian Cenedese @ 2004-10-08 13:17 ` Bob Rossi 0 siblings, 0 replies; 21+ messages in thread From: Bob Rossi @ 2004-10-08 13:17 UTC (permalink / raw) To: Fabian Cenedese; +Cc: gdb On Fri, Oct 08, 2004 at 08:56:19AM +0200, Fabian Cenedese wrote: > > >> >Understood, here is what I am hoping for at a minimum. > >> > > >> > * GDB supports at least 1 MI protocol for an official release. > >> > Supporting multiple MI protocols would be better for me, but > >> > not a requirement. If GDB could support multiple protocols it > >> > would improve the chances of a given front end working with a > >> > given GDB. > >> > >> But by "support" what do you mean - even a dictionary definition. GDB > >> includes at least one MI implementation, but that says nothing about how > >> well it is either implemented or supported. > > > >That's a good question. > > > >Well, by support I simply mean, GDB is officially saying that a > >particular MI protocol is implemented as it should be, that it is tested > >to make sure that it works to the best of the GDB developers knowledge and > >that it is safe to use by front ends. > > > >I am assuming that MI protocols in development ( right after a version > >bump, but before a major release ) is considered unsupported. By this I > >guess I mean that it should not be used by front ends until it is > >stable. Maybe a better word for "support" in this context is "stable". > > I think the implementation grade is quite important. Though mi2 is > considered now the official and stable mi version I find that half of it > is unimplemented which makes it somehow useless for me. From > this point of view I'd say mi2 is the development version. > (And yes, I'm not only complaining, I have started implementing some > of the missing mi functions.) Yes, I understand what you mean here, however, it is a slightly different problem. I am strictly calling an MI protocol a "development version of MI" if the MI output syntax has not been nailed down ( I've got the hammer ) for an official release. I know there are other reasons why a version of MI could be under development, I am just picking on this one case. I've already described the problem were GDB is released with a stable MI protocol. Then development begins for the next release. A backwards incompatibility happens and the MI version is bumped and the MI output syntax changes. Before the next release another incompatible change can occur and the MI output syntax could change again without a version bump. For this reason, a front end could never communicate with all of these MI protocols ( different grammars ), until a release has been made and the protocol syntax is stable. Even though I might be asking hypothetical questions, I was trying to determine what things would cause the MI protocol to get bumped, so we could figure out what constitutes a development version and what is a stable version. This is why I asked if adding new functions bumps the version, however, several people suggested it shouldn't. Thanks, Bob Rossi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-06 22:36 ` Bob Rossi 2004-10-07 2:40 ` Andrew Cagney @ 2004-10-08 7:17 ` Bob Rossi 2004-10-08 12:41 ` Eli Zaretskii 1 sibling, 1 reply; 21+ messages in thread From: Bob Rossi @ 2004-10-08 7:17 UTC (permalink / raw) To: Andrew Cagney, gdb On Wed, Oct 06, 2004 at 05:26:52PM -0400, Bob Rossi wrote: > On Wed, Oct 06, 2004 at 04:12:32PM -0400, Andrew Cagney wrote: > > Bob, what's your overall objective here? Perhaphs our lack of > > appreciation of your overriding goals is the reason that some (at least > > I) are feeling somewhat puzzled and confused. Andrew, I would really like some closure on these issues, and since you are the only MI maintainer that responds publically, I figured you could help me out here. I asked this question a week ago and still do not know the answer. This is some information I must know in order to figure out how my front end will deal with different versions of GDB, including CVS snapshots. When I use "support" below, I mainly mean tested in the testsuite and considered stable. > * I would like to know what GDB's policy is in regards to supporting old > MI protocols. ( I have received several opposing views on this ) A new way to phrase this would be, for a given release of GDB (not a CVS snapshot), does that release support one MI protocol, or does it support several MI protocols. The MI protocols need to be tested and stable. A backwards incompatible change would bump the revision. > * I would like to ensure that my front end works well with snapshots > of GDB. I do not want to work with the MI development protocol, I > just want to work with the last officially supported protocol. For CVS snapshots, does GDB only support (tested) the development MI protocol? or does it support the last stable protocol? or does it support multiple stable protocols? A backwards incompatible change at this point would bump the revision at first, but every other backwards compatible revision would not bump the revision until the release, which then the protocol becomes tested and stable. > * I would like to make sure that development protocols are never used > by my front end and that I can figure out all of the officially > supported MI protocols that a given GDB supports. This issue can have different solutions if we know the answer to the questions above. Thanks, Bob Rossi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-08 7:17 ` Bob Rossi @ 2004-10-08 12:41 ` Eli Zaretskii 2004-10-08 13:23 ` Bob Rossi 2004-10-08 16:28 ` Daniel Jacobowitz 0 siblings, 2 replies; 21+ messages in thread From: Eli Zaretskii @ 2004-10-08 12:41 UTC (permalink / raw) To: Bob Rossi; +Cc: cagney, gdb > Date: Thu, 7 Oct 2004 22:32:43 -0400 > From: Bob Rossi <bob@brasko.net> > > > * I would like to know what GDB's policy is in regards to supporting old > > MI protocols. ( I have received several opposing views on this ) > > A new way to phrase this would be, for a given release of GDB (not a CVS > snapshot), does that release support one MI protocol, or does it support > several MI protocols. The MI protocols need to be tested and stable. The answer to this is that, although the latest stable MI version is probably the most stable version to rely upon, the old MI versions are also supported to the degree that there are tests in the test suite that exercise them. For example, currently there are tests for mi1 although the latest MI version is mi2. Of course, bugs in MI versions other than the latest will probably not be corrected. > > * I would like to ensure that my front end works well with snapshots > > of GDB. I do not want to work with the MI development protocol, I > > just want to work with the last officially supported protocol. > > For CVS snapshots, does GDB only support (tested) the development MI > protocol? or does it support the last stable protocol? or does it > support multiple stable protocols? Again, the answer is that the support guarantee is the same for the CVS versions: whatever the test suite exercises is supported to the same degree. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-08 12:41 ` Eli Zaretskii @ 2004-10-08 13:23 ` Bob Rossi 2004-10-08 13:42 ` Eli Zaretskii 2004-10-08 16:34 ` Daniel Jacobowitz 2004-10-08 16:28 ` Daniel Jacobowitz 1 sibling, 2 replies; 21+ messages in thread From: Bob Rossi @ 2004-10-08 13:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cagney, gdb On Fri, Oct 08, 2004 at 01:41:50PM +0200, Eli Zaretskii wrote: > > Date: Thu, 7 Oct 2004 22:32:43 -0400 > > From: Bob Rossi <bob@brasko.net> > > > > > * I would like to know what GDB's policy is in regards to supporting old > > > MI protocols. ( I have received several opposing views on this ) > > > > A new way to phrase this would be, for a given release of GDB (not a CVS > > snapshot), does that release support one MI protocol, or does it support > > several MI protocols. The MI protocols need to be tested and stable. > > The answer to this is that, although the latest stable MI version is > probably the most stable version to rely upon, the old MI versions are > also supported to the degree that there are tests in the test suite > that exercise them. For example, currently there are tests for mi1 > although the latest MI version is mi2. > > Of course, bugs in MI versions other than the latest will probably not > be corrected. Right, I wouldn't expect them to be. OK, Andrew gave me the exact opposite answer here. That is why I asked again http://sources.redhat.com/ml/gdb/2004-10/msg00177.html maybe I'm wrong, and you guys are saying the same thing? > > > * I would like to ensure that my front end works well with snapshots > > > of GDB. I do not want to work with the MI development protocol, I > > > just want to work with the last officially supported protocol. > > > > For CVS snapshots, does GDB only support (tested) the development MI > > protocol? or does it support the last stable protocol? or does it > > support multiple stable protocols? > > Again, the answer is that the support guarantee is the same for the > CVS versions: whatever the test suite exercises is supported to the > same degree. It is important to me that the CVS snapshots try to at least honor the last major MI version before the version bump. Is this something everyone thinks will be possible? I do understand that old MI protocols could be dropped because of maintenance issues. Would we go as far as dropping the last stable protocol, this could potentially be a problem for me. Thanks, Bob Rossi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-08 13:23 ` Bob Rossi @ 2004-10-08 13:42 ` Eli Zaretskii 2004-10-08 16:34 ` Daniel Jacobowitz 1 sibling, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2004-10-08 13:42 UTC (permalink / raw) To: Bob Rossi; +Cc: cagney, gdb > Date: Fri, 8 Oct 2004 08:13:21 -0400 > From: Bob Rossi <bob@brasko.net> > Cc: cagney@gnu.org, gdb@sources.redhat.com > > OK, Andrew gave me the exact opposite answer here. That is why I asked again > http://sources.redhat.com/ml/gdb/2004-10/msg00177.html > > maybe I'm wrong, and you guys are saying the same thing? It surely sounds like Andrew is saying that all versions of MI except the latest one are completely unsupported and broken, but I really doubt he meant that. After all, if that were the case, why would we bother to keep those older versions in GDB? But please wait for Andrew's definitive response. > It is important to me that the CVS snapshots try to at least honor the > last major MI version before the version bump. Is this something > everyone thinks will be possible? I think that an MI version that was just been superceded by a newer one will not bitrot right away. So you can count on it for quite some time. Also, all the tests for that version are still there to make sure it works at least as well as it used to. > I do understand that old MI protocols could be dropped because of > maintenance issues. Would we go as far as dropping the last stable > protocol, this could potentially be a problem for me. I don't think the GDB maintainers will ever agree to such a radical measure, even if someone were to suggest it. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-08 13:23 ` Bob Rossi 2004-10-08 13:42 ` Eli Zaretskii @ 2004-10-08 16:34 ` Daniel Jacobowitz 1 sibling, 0 replies; 21+ messages in thread From: Daniel Jacobowitz @ 2004-10-08 16:34 UTC (permalink / raw) To: Eli Zaretskii, cagney, gdb On Fri, Oct 08, 2004 at 08:13:21AM -0400, Bob Rossi wrote: > It is important to me that the CVS snapshots try to at least honor the > last major MI version before the version bump. Is this something > everyone thinks will be possible? Try, yes. Succeed, no, not always. In an earlier message I described various fixes to GDB's internals which would make honoring an MI protocol that did not express them extremely difficult. -- Daniel Jacobowitz ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-08 12:41 ` Eli Zaretskii 2004-10-08 13:23 ` Bob Rossi @ 2004-10-08 16:28 ` Daniel Jacobowitz 2004-10-08 18:57 ` Eli Zaretskii 1 sibling, 1 reply; 21+ messages in thread From: Daniel Jacobowitz @ 2004-10-08 16:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Bob Rossi, cagney, gdb On Fri, Oct 08, 2004 at 01:41:50PM +0200, Eli Zaretskii wrote: > > Date: Thu, 7 Oct 2004 22:32:43 -0400 > > From: Bob Rossi <bob@brasko.net> > > > > > * I would like to know what GDB's policy is in regards to supporting old > > > MI protocols. ( I have received several opposing views on this ) > > > > A new way to phrase this would be, for a given release of GDB (not a CVS > > snapshot), does that release support one MI protocol, or does it support > > several MI protocols. The MI protocols need to be tested and stable. > > The answer to this is that, although the latest stable MI version is > probably the most stable version to rely upon, the old MI versions are > also supported to the degree that there are tests in the test suite > that exercise them. For example, currently there are tests for mi1 > although the latest MI version is mi2. That's not true any more; there were, and they were removed. My understanding is that we have been keeping the last stable protocol in addition to the current development protocol. Of course, there is not much in the way of sample size here! -- Daniel Jacobowitz ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-08 16:28 ` Daniel Jacobowitz @ 2004-10-08 18:57 ` Eli Zaretskii 2004-10-09 11:14 ` Andrew Cagney 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2004-10-08 18:57 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: bob, cagney, gdb > Date: Fri, 8 Oct 2004 09:42:19 -0400 > From: Daniel Jacobowitz <drow@false.org> > Cc: Bob Rossi <bob@brasko.net>, cagney@gnu.org, gdb@sources.redhat.com > > That's not true any more; there were, and they were removed. That sounds like a mistake to me. A bunch of small files like that cannot possibly do any harm. Andrew, can we resurrect them, please? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-08 18:57 ` Eli Zaretskii @ 2004-10-09 11:14 ` Andrew Cagney 2004-10-10 4:06 ` Bob Rossi 0 siblings, 1 reply; 21+ messages in thread From: Andrew Cagney @ 2004-10-09 11:14 UTC (permalink / raw) To: Eli Zaretskii, Daniel Jacobowitz, bob; +Cc: gdb @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes @value{GDBN} to use the @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, , The @sc{gdb/mi} Interface}) included since @var{GDBN} version 6.0. The previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3 and selected with @samp{--interpreter=mi1}, is deprecated. Earlier @sc{gdb/mi} interfaces are no longer supported. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-09 11:14 ` Andrew Cagney @ 2004-10-10 4:06 ` Bob Rossi 2004-10-11 2:00 ` Bob Rossi 0 siblings, 1 reply; 21+ messages in thread From: Bob Rossi @ 2004-10-10 4:06 UTC (permalink / raw) To: Andrew Cagney; +Cc: Eli Zaretskii, Daniel Jacobowitz, gdb On Fri, Oct 08, 2004 at 05:35:22PM -0400, Andrew Cagney wrote: > @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes > @value{GDBN} to use the @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, , > The @sc{gdb/mi} Interface}) included since @var{GDBN} version 6.0. The > previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3 and > selected with @samp{--interpreter=mi1}, is deprecated. Earlier > @sc{gdb/mi} interfaces are no longer supported. This is basically what I need to know. I've asked several times and would very much appreciate an answer from the people that are capable of giving it. (The answer could be a simple yes or no) * Will GDB support at least one stable MI protocol for an official release? (This answer is obviously "yes", and does not have to be answered) * Will GDB support more than one stable MI protocols for an official release? * Will GDB support one stable MI protocol for a CVS snapshot? * Will GDB support more than one stable MI protocols for a CVS snapshot? BTW, The word "will" means that even if GDB supports only 1 official protocol currently, what about in the future? These questions are a prerequisite in determining how my front end will be able to interface with GDB. They are also a prerequisite to solving the MI handshaking problem. Thanks, Bob Rossi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-10 4:06 ` Bob Rossi @ 2004-10-11 2:00 ` Bob Rossi 2004-10-11 14:12 ` Andrew Cagney 0 siblings, 1 reply; 21+ messages in thread From: Bob Rossi @ 2004-10-11 2:00 UTC (permalink / raw) To: Andrew Cagney, Eli Zaretskii, Daniel Jacobowitz, gdb On Fri, Oct 08, 2004 at 06:10:26PM -0400, Bob Rossi wrote: > On Fri, Oct 08, 2004 at 05:35:22PM -0400, Andrew Cagney wrote: > > @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes > > @value{GDBN} to use the @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, , > > The @sc{gdb/mi} Interface}) included since @var{GDBN} version 6.0. The > > previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3 and > > selected with @samp{--interpreter=mi1}, is deprecated. Earlier > > @sc{gdb/mi} interfaces are no longer supported. > > This is basically what I need to know. I've asked several times and > would very much appreciate an answer from the people that are capable of > giving it. (The answer could be a simple yes or no) > > * Will GDB support at least one stable MI protocol for an official release? > (This answer is obviously "yes", and does not have to be answered) > * Will GDB support more than one stable MI protocols for an official release? > * Will GDB support one stable MI protocol for a CVS snapshot? > * Will GDB support more than one stable MI protocols for a CVS snapshot? > > BTW, The word "will" means that even if GDB supports only 1 official protocol currently, > what about in the future? > > These questions are a prerequisite in determining how my front end will > be able to interface with GDB. They are also a prerequisite to solving the > MI handshaking problem. Andrew, I know that you are a very busy person. You have asked me several questions and I politely responded to you. I would appreciate it if you could give me the same respect. Could you please answer the questions I've asked you, not only from this Email but from the rest of the ones in this thread? From your lack of response to my questions (at least you respond), and the *complete* lack of response from the other MI maintainers, I would say that there is a problem with the maintenance of the MI section. The problem is simply that I can not get general and simple answers about the MI code. I feel that this should be something accomplishable ... do you? Thanks, Bob Rossi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-11 2:00 ` Bob Rossi @ 2004-10-11 14:12 ` Andrew Cagney 2004-10-11 17:22 ` Bob Rossi 0 siblings, 1 reply; 21+ messages in thread From: Andrew Cagney @ 2004-10-11 14:12 UTC (permalink / raw) To: Bob Rossi; +Cc: Eli Zaretskii, Daniel Jacobowitz, gdb C'mon Bob, it's the Canadian thanksgiving long weekend! Strewth! > On Fri, Oct 08, 2004 at 06:10:26PM -0400, Bob Rossi wrote: > >>> On Fri, Oct 08, 2004 at 05:35:22PM -0400, Andrew Cagney wrote: >> >>>> > @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes >>>> > @value{GDBN} to use the @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, , >>>> > The @sc{gdb/mi} Interface}) included since @var{GDBN} version 6.0. The >>>> > previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3 and >>>> > selected with @samp{--interpreter=mi1}, is deprecated. Earlier >>>> > @sc{gdb/mi} interfaces are no longer supported. ... and it is lifted straight from the manual. That you did read the manual right? >>> This is basically what I need to know. I've asked several times and >>> would very much appreciate an answer from the people that are capable of >>> giving it. (The answer could be a simple yes or no) >>> * Will GDB support at least one stable MI protocol for an official release? >>> (This answer is obviously "yes", and does not have to be answered) >>> * Will GDB support more than one stable MI protocols for an official release? In the past GDB tested both mi1 and mi2 so that that stage they were probably described as "supported". Now that only mi2 is tested, nad mi1 is deprecated, your call. >>> * Will GDB support one stable MI protocol for a CVS snapshot? The above does, right? >>> * Will GDB support more than one stable MI protocols for a CVS snapshot? Who knows, I still don't see the point of all this, in particular, if you're going to implement a library, why it has to be kept separate to GDB? And as others have pointed out, you're creating a problem when there isn't one. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-11 14:12 ` Andrew Cagney @ 2004-10-11 17:22 ` Bob Rossi 2004-10-12 22:15 ` Michael Chastain 0 siblings, 1 reply; 21+ messages in thread From: Bob Rossi @ 2004-10-11 17:22 UTC (permalink / raw) To: Andrew Cagney; +Cc: Eli Zaretskii, Daniel Jacobowitz, gdb On Sun, Oct 10, 2004 at 10:56:49PM -0400, Andrew Cagney wrote: > C'mon Bob, it's the Canadian thanksgiving long weekend! Strewth! hehe, thanks for answering my questions! I'm just excited about getting things working, that's all. > >On Fri, Oct 08, 2004 at 06:10:26PM -0400, Bob Rossi wrote: > > > >>>On Fri, Oct 08, 2004 at 05:35:22PM -0400, Andrew Cagney wrote: > >> > >>>>> @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes > >>>>> @value{GDBN} to use the @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, , > >>>>> The @sc{gdb/mi} Interface}) included since @var{GDBN} version 6.0. > >>>>The > >>>>> previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3 > >>>>and > >>>>> selected with @samp{--interpreter=mi1}, is deprecated. Earlier > >>>>> @sc{gdb/mi} interfaces are no longer supported. > > ... and it is lifted straight from the manual. That you did read the > manual right? Yes, i did, thanks. > >>>This is basically what I need to know. I've asked several times and > >>>would very much appreciate an answer from the people that are capable of > >>>giving it. (The answer could be a simple yes or no) > > >>> * Will GDB support at least one stable MI protocol for an official > >>> release? > >>> (This answer is obviously "yes", and does not have to be answered) > >>> * Will GDB support more than one stable MI protocols for an official > >>> release? > > In the past GDB tested both mi1 and mi2 so that that stage they were > probably described as "supported". Now that only mi2 is tested, nad mi1 > is deprecated, your call. Yes, and if MI3 were created, MI2 would probably stick around for a while, or at least until the release, right? > >>> * Will GDB support one stable MI protocol for a CVS snapshot? > > The above does, right? > > >>> * Will GDB support more than one stable MI protocols for a CVS > >>> snapshot? > > Who knows, > > I still don't see the point of all this, in particular, if you're going > to implement a library, why it has to be kept separate to GDB? > > And as others have pointed out, you're creating a problem when there > isn't one. I feel like Kerry, and everyone keeps calling me a flip flopper :) Listen, there is a reason I need to know. I am trying to solve the problem of probing GDB from a front end to determine what version/versions of MI a particular version of GDB supports. If GDB is only going to support 1 stable MI protocol, then GDB can simply output the protocol that it supports when it is started up. There is no reason to "probe" it, it can just tell the front end what protocol it speaks. However, if it can use multiple MI versions, then a handshake algorithm must take place. Basically, GDB starts up saying that it can speak several different protocols, and then the front end picks one, and then GDB uses that protocol. The implementation is easier for the first case. However, I think the second case is necessary. Bob Rossi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Bob's MI objective 2004-10-11 17:22 ` Bob Rossi @ 2004-10-12 22:15 ` Michael Chastain 0 siblings, 0 replies; 21+ messages in thread From: Michael Chastain @ 2004-10-12 22:15 UTC (permalink / raw) To: cagney, bob; +Cc: gdb, eliz, drow Bob Rossi writes: > However, if it can use multiple MI versions, then a handshake algorithm > must take place. Basically, GDB starts up saying that it can speak > several different protocols, and then the front end picks one, and then > GDB uses that protocol. I haven't followed this thread too closely, but this seems simple and natural to me. Michael ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2004-10-12 14:03 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-10-06 20:13 Bob's MI objective Andrew Cagney 2004-10-06 22:36 ` Bob Rossi 2004-10-07 2:40 ` Andrew Cagney 2004-10-07 17:20 ` Bob Rossi 2004-10-07 20:50 ` Andrew Cagney 2004-10-07 22:42 ` Bob Rossi 2004-10-08 8:40 ` Fabian Cenedese 2004-10-08 13:17 ` Bob Rossi 2004-10-08 7:17 ` Bob Rossi 2004-10-08 12:41 ` Eli Zaretskii 2004-10-08 13:23 ` Bob Rossi 2004-10-08 13:42 ` Eli Zaretskii 2004-10-08 16:34 ` Daniel Jacobowitz 2004-10-08 16:28 ` Daniel Jacobowitz 2004-10-08 18:57 ` Eli Zaretskii 2004-10-09 11:14 ` Andrew Cagney 2004-10-10 4:06 ` Bob Rossi 2004-10-11 2:00 ` Bob Rossi 2004-10-11 14:12 ` Andrew Cagney 2004-10-11 17:22 ` Bob Rossi 2004-10-12 22:15 ` Michael Chastain
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).