Re: MI non-stop mode spec

[Vladimir Prus <ghost at cs dot msu dot su>]

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