Re: MI non-stop mode spec

[Pawel Piech <pawel.piech@windriver.com>]

Hi Vladimir,
Thank you very much for the reply and for considering my input.  Below 
are my replies:

Vladimir Prus wrote:
> On Friday 21 March 2008 21:12:34 Pawel Piech wrote:
>   
>> Hi Vladimir,
>> Thank you for putting together this proposal for extending the MI 
>> protocol to allow non-stop debugging.  In general I think the changes 
>> you are proposing are positive I just have two criticisms when looking 
>> at this proposal from the client's point of view.  BTW, I work with Marc 
>> on the Eclipse DSF-GDB integration.  One disclaimer I should make is 
>> that I'm not familiar with any of the GDB internals so I don't know what 
>> is easier/more difficult.  I'm only speaking from a client's point of view.
>>
>> 1) Changing the protocol to be (partially) stateless by adding -thread 
>> and -global options to multitude of commands is not backwards compatible. 
>>     
>
> Note that --global option is not longer proposed.
>   
I saw this in the prior discussions, although I didn't see what was the 
the proposed replacement.  For a UI, it is still very useful to be able 
to resume or suspend all threads with a single command.
>   
>>  From the clients point of view, keeping the protocol backward 
>> compatible is a great benefit.  I'm not a big fan of -thread-select, but 
>> it's there and trying to remove it now I think will cause more problems 
>> than it solves. 
>>
>> You mentioned that when switching to non-stop mode there is an inherent 
>> race condition in using -thread-select because GDB may switch current 
>> threads due to an async stopped event.  A less jarring change to the 
>> protocol than adding -thread/-global to all the commands would be to 
>> change the behavior of *stopped not to switch the current thread.  To 
>> remain backward compatible with older GDB versions, i.e. to work with 
>> old *stopped event behavior, MI clients can make the assumption that 
>> after a stopped event the current thread is not known and send a 
>> -thread-select before sending new commands.  One objection to this 
>> change may be that it's not forward compatible and older clients will 
>> not work with the new MI protocol version, but I think older clients 
>> will not work with GDB in non-stop mode anyhow with the protocol changes 
>> that you propose, so that point should make no difference in your decision.
>>     
>
> So, we have establishes that current GDB behaviour just is not suitable
> for non-stop mode. It can be changed in two ways:
>
> - Making GDB never change the current thread on its own
> - Adding --thread option
>
> <snip>
>   
> My conclusion is that the effect on compatibility and the implementation
> effort on the frontend side are basically the same, so we can judge the
> alternatives based on how good they are from the protocol standpoint.
>   
I have to disagree with you on this point.  There is different impact on 
compatibility for the client between these two options.  The first 
change in protocol would allow the client to more easily remain backward 
compatible with old versions of GDB as I described above.  Adding the 
-thread option would force clients to query the GDB version explicitly 
and in order to know to use different a format of commands that now 
require the -thread parameter.  Just as you worry that the new version 
of GDB should work with older clients.  Clients worry that they won't 
work with old versions of GDB.  So if you would like quicker adoption of 
this new non-stop debugging feature by clients, I urge you not to 
introduce the -thread parameter. 
> I think I still prefer --thread, as it allows the frontend to eventually
> get rid of all the change-thread-do-operation-restore-thread logic. 
Getting rid of -thread-select is not going to make the MI protocol 
stateless, as there is still a current stack frame.  So the state 
handling logic would have to remain... at least in the Eclipse 
implementation.  Besides, every client that works with GDB already has 
this logic working and and time-tested, so besides pursuing an 
ideological goal I don't think you're doing the clients any favors by 
getting rid of -thread-select.  I would be very curious to hear what 
other clients think of this change though.
> The
> other alternative is less clean -- it means that there will be actually
> three "current threads". One is the current thread from the frontend POV.
> Another is the current thread variable that is implicitly used by most
> of gdb codebase (which necessary changes as gdb works). The last is
> the "current thread" for MI commands. Having those 3 current threads
> and keeping those in sync sounds nasty.
>   
Eclipse integrations with GDB already track the first two current 
threads efficiently.  I would even say that the logic to track it in 
DSF-GDB is rather elegant :-)  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. 
>> I don't fully understand why disabling CLI commands is desired, but I'm 
>> guessing it's because the CLI commands would still rely on the current 
>> thread.  If so, then keeping the MI protocol stateful would hopefully 
>> address that concern and not force you to disable the CLI interface, 
>> which would be unfortunate.
>>     
>
> The reason I've proposed postponing CLI support is purely practical. Right now,
> GDB explicitly decides which commands are allowed while the target is running.
> In order to enable each specific command, one should:
>
>   - decide what restrictions, if any, that command should have
>   - actually try that command, and make sure GDB works fine, that is does
>   not try to access frames in running threads, and so on.
>
> This takes time. 
>
> The problem of implicit thread switch is not so bad, because user typing
> commands in GDB console probably waits for result of each one before
> typing next. 
>
> 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. 
>> 2) The proposal does not address multi-process debugging in any way.  I 
>> understand that multi-process (or multi-core) debugging is not part of 
>> this proposal, but I think keeping that use case in mind when making 
>> this change would make it less painful for the clients when we actually 
>> get to that point.  In context of multi-process debugging, options such 
>> as -global and fields such as "all" are rather ambigeous.  Instead, I 
>> have the following suggestion:
>>
>> Assign an ID to a process in the same name space as threads.  Until 
>> multi-process debugging is implemented you could just reserve a thread 
>> id, such as "0" to be the process thread ID.  For completeness this ID 
>> would be returned already in the thread-id field of the response to 
>> -target-select command  In order to operate on a whole process context 
>> use a -thread-select command with the process context id (followed by 
>> the command).  -thread-list-ids would list threads within that process, 
>> normally starting with "1".  In reporting stopped events, (in non-stop 
>> debugging mode) if a thread has suspended, use the thread-id field to 
>> indicate which thread has triggered the stop.  Use a separate field: 
>> container-id, to indicate whether the whole process stopped, assuming 
>> that some events still cause all threads to stop.  
>>     
>
> Can we rename 'container-id' to 'process-id', as that is what it is?
>   
I would guess is that there are more GDB extensions out there that 
connect to multiple cores rather than multiple processes.  But of course 
it's OK to change it, it's just a name.
> I actually thought that the path forward for multi-process debugging
> would be to add the --process option.
>   
I had an feeling you would say that :-)  The "-process" option would 
have to be added to just about every MI command, and just as -thread it 
would not be a backward compatible change.  I.e. more work for clients = 
slower adoption.
>> In all-stop mode, the  
>> container-id field would always be present in the stopped event.  I 
>> think that making this change would allow clients to still work with 
>> older versions of GDB in all-stop mode, since thread 0 in all-stop mode 
>> would act like a container thread anyway, resuming and suspending all 
>> threads.
>>     
>
> I'm afraid I don't understand the last sentence. Can you clarify?
>   
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.

One thing that was not clear to me from your proposal is how GDB would 
support all-stop targets with the new version of the protocol (such as 
on chip debugging).  If the answer is, by using the old protocol 
version, I must I admit I'll be rather disappointed.  For a clients, to 
support multiple versions of a protocol indefinitely into the future is 
going to be rather expensive.  I would imagine the same is true for GDB...
> - Volodya
>   
Thank you for your time.  I hope we can keep this conversation going so 
we can reach a conclusion that makes us all happy.  We have mostly the 
same goals, the only difference being whether the GDB or the clients 
will have to do more work to support these new features.  But I hope 
that it's also in GDB's interest to make it easy for clients to adopt 
this new functionality and reach a wider user base quickly.

Sincerely,
Pawel