Reporting non-stop support

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

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
>   

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
>
>
>