Re: MI: "^running" issues

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Thu, 06 Sep 2007 09:10:15 +0200
> From: Fabian Cenedese <Cenedese@indel.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.

Nothing that you can't solve with non-blocking IO.

Debugging multi-threaded code is bad enough in itself.  You don't need
to make matters worse by making gdb itself less deterministic.

Mark