This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: "^running" issues
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