From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10818 invoked by alias); 2 Mar 2007 14:31:20 -0000 Received: (qmail 10807 invoked by uid 22791); 2 Mar 2007 14:31:18 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 02 Mar 2007 14:31:11 +0000 Received: from dsl093-172-095.pit1.dsl.speakeasy.net ([66.93.172.95] helo=caradoc.them.org) by nevyn.them.org with esmtp (Exim 4.63) (envelope-from ) id 1HN8mp-0005Iv-8O; Fri, 02 Mar 2007 09:31:07 -0500 Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HN8mp-0008M5-0M; Fri, 02 Mar 2007 09:31:07 -0500 Date: Fri, 02 Mar 2007 14:31:00 -0000 From: Daniel Jacobowitz To: Fabian Cenedese Cc: gdb@sourceware.org Subject: Re: Improving GDB for multicore and embedded system! Message-ID: <20070302143106.GA32103@caradoc.them.org> Mail-Followup-To: Fabian Cenedese , gdb@sourceware.org References: <45E7E9A7.5050705@st.com> <67048CBE51B1644D89DDD3B7C9F2D19E032884F7@ecamlmw720.eamcs.ericsson.se> <45E7E9A7.5050705@st.com> <5.2.0.9.1.20070302150910.01904440@NT_SERVER> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.1.20070302150910.01904440@NT_SERVER> User-Agent: Mutt/1.5.13 (2006-08-11) 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-03/txt/msg00036.txt.bz2 On Fri, Mar 02, 2007 at 03:20:43PM +0100, Fabian Cenedese wrote: > We can stop any number of threads while the others continue to run > (well, the comm-thread needs to run always or it's rather dull to watch :) > I have once tried to map this onto the threads of gdb. That worked > in so far, that I could get the info about all the threads. But as soon > one was stopped gdb assumed that all we're stopped. So no refreshes > anymore, wrong variable contents etc. Yes, this is an entirely different embedded debugging problem. > The other solution with one instance of gdb for every thread wasn't > very liable either. The biggest images including debug info can be > in the dozens of MB. After gdb has loaded such an image the > memory consumption was in the range of 200MB. Multiply this > with one or two dozen threads and you can imagine how long > it would take to start debugging, not even speaking of the > memory consumption... The expedient hack would be to load the debugging image once, and then fork off separate GDBs to control each target. I don't know how much trouble that would be to get to work. > So I still follow the gdb list here and we would very welcome > any improvements in this area (I know, gdb is open source, we > could do it ourselves etc. Unfortunately neither manpower nor > knowledge) Yes. Unfortunately, I have neither the time nor the urgent need, so I'm not going to do it either :-) I'll just keep hoping. -- Daniel Jacobowitz CodeSourcery