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