Reporting non-stop support

Reporting non-stop support

[Vladimir Prus]

As discussed before, it would be nice if GDB could report if the current
target supports non-stop, so that frontend can act accordingly (even if
"accordingly" means saying "sorry, non-stop is not supported").
However, it's a bit tricky, because until we do "run", the two
targets on the target stack are dummy target and exec_ops -- neither of
which, naturally, have any clue about non-stop.

It's only when we do "run" when find_default_run_target is called, and
something reasonable is pushed to the target stack. Which means that
until we do "run", we don't know if the target supports non-stop, and
when we do "run", it's a bit too later to set non-stop mode.

Any suggestions?

- Volodya

Re: Reporting non-stop support

[Pawel Piech]

I just think this shows how important it is that the client be able to 
use the same protocol to communicate in either mode, and be able to use 
the event data alone to determine what state actually changed on the target.

Cheers,
Pawel

Vladimir Prus wrote:
> As discussed before, it would be nice if GDB could report if the current
> target supports non-stop, so that frontend can act accordingly (even if
> "accordingly" means saying "sorry, non-stop is not supported").
> However, it's a bit tricky, because until we do "run", the two
> targets on the target stack are dummy target and exec_ops -- neither of
> which, naturally, have any clue about non-stop.
>
> It's only when we do "run" when find_default_run_target is called, and
> something reasonable is pushed to the target stack. Which means that
> until we do "run", we don't know if the target supports non-stop, and
> when we do "run", it's a bit too later to set non-stop mode.
>
> Any suggestions?
>
> - Volodya
>   

Re: Reporting non-stop support

[Vladimir Prus]

Pawel Piech wrote:

> I just think this shows how important it is that the client be able to
> use the same protocol to communicate in either mode, and be able to use
> the event data alone to determine what state actually changed on the target.

Heh, I don't think so. Do you really think it's acceptable to have a "non-stop"
checkbox in UI that will not actually work, and find out that it does not work
only when your program stops for the first time -- stopping all threads? I think
this is not acceptable in any way -- regardless of how carefully and politely
gdb phrases "all threads stopped, your real time application is messed up" 
information.

- Volodya

Re: Reporting non-stop support

[Pawel Piech]

I don't think a "non-stop" mode needs to be enabled by a "check box".  
It's more of a property of a target rather than a feature that a user 
requests.  Depending on what kind of target the user is connecting to, 
he will likely know beforehand whether it supports non-stop debugging, 
and if it does, he will naturally want it enabled.

Cheers,
Pawel

Vladimir Prus wrote:
> Pawel Piech wrote:
>
>   
>> I just think this shows how important it is that the client be able to
>> use the same protocol to communicate in either mode, and be able to use
>> the event data alone to determine what state actually changed on the target.
>>     
>
> Heh, I don't think so. Do you really think it's acceptable to have a "non-stop"
> checkbox in UI that will not actually work, and find out that it does not work
> only when your program stops for the first time -- stopping all threads? I think
> this is not acceptable in any way -- regardless of how carefully and politely
> gdb phrases "all threads stopped, your real time application is messed up" 
> information.
>
> - Volodya
>
>
>