Re: MI: "^running" issues

[Fabian Cenedese <Cenedese at indel dot ch>]

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

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

- If gdb ever comes to multiprocess debugging it would need to be
  multithreaded as well. One process can be running and the other
  is stopped. Or you need to issue a gdb command to stop a process.

There may be other cases I can't remember now. But I'd surely
welcome a multithreaded gdb. gdb is needed for many cases, not
just a local program on a linux box.

bye  Fabi