From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13387 invoked by alias); 25 Mar 2008 11:34:48 -0000 Received: (qmail 13378 invoked by uid 22791); 25 Mar 2008 11:34:47 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 25 Mar 2008 11:34:28 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Je7Q4-0005XD-BC for gdb@sources.redhat.com; Tue, 25 Mar 2008 11:34:20 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Mar 2008 11:34:20 +0000 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Mar 2008 11:34:20 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: MI non-stop mode spec Date: Tue, 25 Mar 2008 12:30:00 -0000 Message-ID: References: <200803190016.02072.vladimir@codesourcery.com> <47E3FA92.40409@windriver.com> <200803242016.19140.vladimir@codesourcery.com> <47E7F4D4.9050501@windriver.com> <47E81C22.4000508@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00216.txt.bz2 Pawel Piech wrote: >> I'm afraid I still don't see where the complexity lieth. There's exactly >> one command that a frontend has to emit at startup in order to query >> gdb functionality. Then, it's just a matter of single "if" statement >> to send --thread. >> >> Definitely, this can be done in KDevelop fairly easily. BTW, this is >> not different from other new MI features. For example, I've recently >> added support for pending breakpoints via MI -- which is the -f option >> to -break-insert. KDevelop was also modified to query for presence of >> this features, and use -break-insert -f if available, and fallback to >> emulation otherwise. This works fine, and not particularly complex. >> >> > > Perhaps complexity is in the eye of the beholder :-) In DSF-GDB, the > implementation is divided into services along the lines of the > functionality such as run control, stack, variables, breakpoints, etc. > Depending on GDB version or variant, different services or extensions to > those services can be put together to support a given debugger back > end. BTW, the goal of DSF-GDB is not just to support GDB, it's to > create a set of components that can be re-used to integrate with Eclipse > any debugger that uses the MI protocol. > > If a new feature is added to a particular command, such as the deferred > breakpoints, that single service can be replaced, updated, or extended > as needed. While adding an option across all commands forces changes in > all services. There is a command factory mechanism in CDI-GDB to > abstract some protocol changes which deals with small changes to > individual commands based on the protocol version, which DSF-GDB is > probably going to have to adopt as well. But this mechanism wouldn't be > necessary if the evolution in the protocol was more concerned with > backward compatibility, especially in a case like this where the > protocol change is not really necessary. Yes, I was thinking that a centralised entity that actually sends or creates command can easily add --thread option. > I'm not going to argue this point any further though. It seems that > you've made up your mind on this point and I stated my case clearly > enough. I'm not a GDB committer so it's up to you to make a decision. Thanks; there's more about this issue below. >> >> Well, have a pointer to source code? (Names of files will do, I have >> DSF-GDB source here). >> > The current context in the UI is not MI-debugger specific. And it's > implementation is rather flexible allowing for different simultaneous > current contexts in current windows. The handling of this context is > mostly implemented in the org.eclipse.debug.internal.ui.context package > of the org.eclipse.debug.ui plugin. > > The AbstractMIControl module in org.eclipse.dd.mi plugin handles > tracking of the MI protocol state. It determines when to send > -thread-select or -stack-frame-select based on the context contained > within each command. It's simple, contained, and reliable. Thanks for the pointer, I shall take a look. >>> I can't speak for the GDB internal >>> "current thread", but I assumed that it was the same as the MI protocol >>> current thread. Maybe I didn't make myself clear, but my suggestion was >>> to keep the CLI current thread and MI current thread in sync, and avoid >>> switching the current thread in the CLI interface upon suspended event >>> also. This actually makes a lot of sense even when the command line >>> interface is used without a UI while in non-stop debug mode, because as >>> a user I wouldn't want an asynchronous event to switch the current >>> thread from under me as I'm entering a new command. >>> >> >> That's an interesting issue. I feel like thread switches might not be as >> big issue for CLI user, but probably not switching the thread is indeed >> better. It still seems like unknown amount of work. As I mention, gdb >> currently has one notion of current thread, which it switches often to perform >> its operations. We can introduce 'user-level current thread', and then >> set gdb's current thread to user's current thread before executing any CLI >> operation. However, I suspect this might break things badly, if user >> types new command when gdb is busy doing some run operation. >> > > Thanks for agreeing :-) Like I said, I have no idea of the complexity > of such a change. However, it seems to me that you should be able to > implement a simple protcol-state-tracking logic for both CLI and MI > protocols, and simply simulate the --thread option for commands that > don't supply one. This way you could have both the backward compatible > stateful protocol, and have the -thread option to override it on the > individual commands. This might be actually a reasonable thing. On one thing, not switching the current thread might be good for CLI. On the other hand, I still believe that --thread is ultimately better solution for MI. Then, it might be best to make GDB not to switch threads (benefiting CLI and stateful MI), and also accept --thread for the benefit of newer MI clients. Now there's the catch that --thread is already implemented and is rather straightforward, whereas I expect some corner cases in implementing thread that does not change. I think we'll first get the non-stop mode working with --thread, and then look into making current thread not change. (For avoidance of doubt, "then" means "immediately after" not "someday"). >>>> I guess I probably can enable the -interpreter-exec command for MI, >>>> with the big warning that any given CLI command might not work. >>>> >>>> >>> I think that's a fair compromise. >>> >> >> OK, I have updated the spec. Does DSF-GDB actually use -interpreter-exec, >> as opposed to sending the raw CLI command? >> >> > > Yes, both CDI and DSF integrations with GDB use the -interpreter-exec > command to execute CLI commands. Good. >>> I was trying to explain the mechanics of how clients could remain >>> backward compatible with older GDB versions with my proposed protocol >>> changes. It boils down to the following assumptions (for the client): >>> 1) After a stopped event, the current selected thread is unknown. >>> 2) If multi-container awareness is not yet implemented, container-id="0" >>> 3) If a running/stopped event does not contain a container-id field, >>> then container-id="0" is implied in the event. >>> >> >> What is the benefit of container-id="0" if it's already implied? BTW, >> how does one select thread N in process M in your scheme? >> >> > > In the newer version of the protocol, the container-id field in events > should be explicit. If debugging multiple processes/cores, the > container-id field would indicate whether the whole process/core changed > state, or whether only a given thread suspended. Although, I think I > got ahead of myself a little bit. In the Wind River debugger, the > container-id field actually contains an array container-ids="[...]", and > the same is true for threads, because there are cases where multiple, > but not all threads may suspend with a given event. In order to > indicate that only a thread and not a container changed state, we use > the container-ids field with an empty array. > > Each thread id is unique, even across multiple processes. To switch to > a thread in a different process, only a thread-select is needed. Ah, I see. I guess at this point, support for multiple processes looks like an independent thing, though I hope we'll get back to that relatively soon. Thanks for your feedback, I think it's rather important that frontend developers are getting involved in MI design. - Volodya