From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8495 invoked by alias); 2 Mar 2007 15:22:40 -0000 Received: (qmail 8209 invoked by uid 22791); 2 Mar 2007 15:22:39 -0000 X-Spam-Check-By: sourceware.org Received: from exprod8og54.obsmtp.com (HELO exprod8og54.obsmtp.com) (64.18.3.90) by sourceware.org (qpsmtpd/0.31) with SMTP; Fri, 02 Mar 2007 15:22:28 +0000 Received: from source ([12.110.134.31]) by exprod8ob54.obsmtp.com ([64.18.7.12]) with SMTP; Fri, 02 Mar 2007 07:22:14 PST Received: from pkoning.equallogic.com ([172.16.1.118]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 10:21:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17896.16613.317537.597215@gargle.gargle.HOWL> Date: Fri, 02 Mar 2007 15:22:00 -0000 From: Paul Koning To: gdb@sourceware.org Subject: Re: Improving GDB for multicore and embedded system! References: <67048CBE51B1644D89DDD3B7C9F2D19E032884F7@ecamlmw720.eamcs.ericsson.se> <45E7E9A7.5050705@st.com> <20070302135424.GA30113@caradoc.them.org> <1172847786.2170.24.camel@localhost.localdomain> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid 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/msg00038.txt.bz2 I have some experience with multicore debugging and hacking GDB for that. In our case, we have two cores that have the same instruction architecture. But they are running different OS, and one is running 64-bit code while the other is running 32-bit. For live debug, we use two copies of GDB. Yes, that uses up some more VM for the multiple symbol tables. No problem, workstation memory is cheap and easy to get. Each core has a stub, so we can do remote debug via its stub. (If they had to share a stub, which may happen at some point, I'll probably just put in a mux widget that continues to create the appearance of separate stubs.) For crash dump analysis, I get all of memory in a single dump file. Debugging that with two GDBs would be possible but annoying, so I added hacks to the dump analyzer machinery to allow it to switch between the two OS views. It switches address spaces (easy) and it switches executable file symbol tables (very hard). Fortunately, the kernel doesn't have shared libs or the like, it's all one file. This works just well enough to make it practical. It does occasionally mess up. For dump analysis that's not too big a problem, just restart GDB. For live system debug that would create the risk of losing control, which is one reason why we don't do it there. If you have a situation where the multiple cores can be presented to GDB as threads of a single image, the thread machinery should work. If that model doesn't fit, I think the best way to proceed would be to use multiple GDBs, and buy more PC DRAM if necessary. That would be especially true if the various cores differ enough that a single GDB doesn't understand all of them even after putting the multiarch machinery to work. The notion that you debug exactly one executable file seems to be very much fundamental in GDB. You can hack around it but the result is messy and not very stable. Or I suppose if you have enough help from the GDB experts you can redesign GDB to eliminate this assumption. I don't know how long that would take and how hard it would be. Personally, if I had a need for this kind of debug support, I'd just use the multiple GDBs and ask the boss for more memory. paul