Re: MI: "^running" issues

[Vladimir Prus <ghost@cs.msu.su>]

Fabian Cenedese wrote:

> 
>>> > What commands are actually meaningful to emit while target are
>>> > running
>>> 
>>> A less trivial example is "info break" (to see
>>> what breakpoints were already hit during execution up to now, in case
>>> your "commands" for the breakpoints continue the target).
>>
>>Technically speaking, you don't need async for that -- you can interrupt
>>the target, provide output, and then go on. Making this async will maybe
>>cut some fraction of section from the run time, why do we care?
> 
> I'm working on embedded targets and a multithreaded gdb would help
> for many cases.
> 
> - A lot of times the hardware is controlling a machine or some system
>   that is highly optimized for speed. Any interruption could disturb the
>   process or even throw the whole thing out (Imagine a motor that is
>   running and not stopped because the end position was not detected).
> 
> - The connection to the target can be Ethernet but also a slow SIO.
>   So any communication can take quite some time (for CPUs, not
>   for humans). So it may not be just a fraction of a second.

Do you have a communication channel that can talk with the device
while the program is running? 

> - Even while the target is running it's useful to watch some values.
>   These aren't necessarily process variables that can be read by some
>   other means as a visualisation might do. gdb with its debug info is
>   the only way to get there then. And this is only possible if gdb is
>   responding even while the target is running.

This seems a valid usecase; I can find essentially the same request
in the archive.

- Volodya