From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29814 invoked by alias); 6 Sep 2007 08:12:56 -0000 Received: (qmail 29805 invoked by uid 22791); 6 Sep 2007 08:12:55 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Sep 2007 08:12:48 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id l868ChNF029149; Thu, 6 Sep 2007 10:12:43 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id l868ChcE001895; Thu, 6 Sep 2007 10:12:43 +0200 (CEST) Date: Thu, 06 Sep 2007 08:24:00 -0000 Message-Id: <200709060812.l868ChcE001895@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: Cenedese@indel.ch CC: gdb@sources.redhat.com In-reply-to: <5.2.0.9.1.20070906085944.01d61e20@localhost> (message from Fabian Cenedese on Thu, 06 Sep 2007 09:10:15 +0200) Subject: Re: MI: "^running" issues References: <200709041653.22357.ghost@cs.msu.su> <5.2.0.9.1.20070906085944.01d61e20@localhost> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00045.txt.bz2 > Date: Thu, 06 Sep 2007 09:10:15 +0200 > From: Fabian Cenedese > > >> > 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