From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7214 invoked by alias); 2 Mar 2007 14:21:20 -0000 Received: (qmail 7185 invoked by uid 22791); 2 Mar 2007 14:21:17 -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; Fri, 02 Mar 2007 14:21:09 +0000 Received: from indel.ch ([84.73.31.26]) by ms9.webland.ch (Webland.MailServer.v.8.3.5) with ASMTP id HRX68103 for ; Fri, 02 Mar 2007 15:21:03 +0100 Received: from FABI.indel.ch [192.168.1.91] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Fri, 02 Mar 2007 15:21:02 +0100 Message-Id: <5.2.0.9.1.20070302150910.01904440@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 [via SMTPAuth 0.9, bisswanger.com] Date: Fri, 02 Mar 2007 14:21:00 -0000 To: gdb@sourceware.org From: Fabian Cenedese Subject: Re: Improving GDB for multicore and embedded system! In-Reply-To: <20070302135424.GA30113@caradoc.them.org> References: <45E7E9A7.5050705@st.com> <67048CBE51B1644D89DDD3B7C9F2D19E032884F7@ecamlmw720.eamcs.ericsson.se> <45E7E9A7.5050705@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sourceware.org X-Return-Path: cenedese@indel.ch X-WLGenuine-Reason: [FILTER]=Local or Smtp Auth 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/msg00035.txt.bz2 At 08:54 02.03.2007 -0500, Daniel Jacobowitz wrote: >On Fri, Mar 02, 2007 at 10:08:55AM +0100, Denis PILAT wrote: >> Today multicore debugging means multiple instance of gdb running at the >> same time. I don't know how possible it is to enhance gdb so that it can >> handle multiple programs running on different architecture. >> I guess Daniel should have a good vision on that. > >No one has ever convinced me that there's a good reason to do this, >rather than wire up things like DSF to drive multiple GDB's, if the >cores are not all running the same architecture and program image. If >they are, we generally present them as threads, and that works very >well. Actually that's the most important reason why we DON'T use gdb now. Because it can't cope with our embedded OS organization. We have multiple threads in the embedded device which are completely independent, so I should rather call them processes. The whole system is built and linked (from C++) as one image, downloaded and started, so the code and debug info is for all processes the same. 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. 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... 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) Thanks bye Fabi