From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30747 invoked by alias); 6 Sep 2007 07:20:35 -0000 Received: (qmail 30739 invoked by uid 22791); 6 Sep 2007 07:20:34 -0000 X-Spam-Check-By: sourceware.org Received: from ms9.webland.ch (HELO ms9.webland.ch) (194.209.78.139) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Sep 2007 07:20:26 +0000 Received: from indel.ch ([84.73.31.54]) by ms9.webland.ch (Webland.MailServer.v.8.9.6) with ASMTP id LQA42923 for ; Thu, 06 Sep 2007 09:20:23 +0200 Received: from FABI.indel.ch [192.168.1.91] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Thu, 06 Sep 2007 09:19:26 +0200 Message-Id: <5.2.0.9.1.20070906085944.01d61e20@localhost> X-Sender: cenedese@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 [via SMTPAuth 0.9, bisswanger.com] Date: Thu, 06 Sep 2007 08:12:00 -0000 To: gdb@sources.redhat.com From: Fabian Cenedese Subject: Re: MI: "^running" issues In-Reply-To: <200709061046.21723.ghost@cs.msu.su> References: <200709041653.22357.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sources.redhat.com X-Return-Path: cenedese@indel.ch X-IsSubscribed: yes 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/msg00044.txt.bz2 >> > 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