From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21201 invoked by alias); 5 Dec 2003 07:28:55 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21194 invoked from network); 5 Dec 2003 07:28:53 -0000 Received: from unknown (HELO smtp1.vsnl.net) (203.200.235.231) by sources.redhat.com with SMTP; 5 Dec 2003 07:28:53 -0000 Received: from 219.65.86.69 ([127.0.0.1]) by smtp1.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HPE005JCVDSF2@smtp1.vsnl.net> for gdb@sources.redhat.com; Fri, 05 Dec 2003 12:57:49 +0530 (IST) Received: from ([219.65.86.69]) by smtp1.vsnl.net (InterScan E-Mail VirusWall Unix); Fri, 05 Dec 2003 12:57:49 +0530 (IST) Date: Fri, 05 Dec 2003 07:28:00 -0000 From: "Amit S. Kale" Subject: Re: GDB for Multiprocessor Architecture In-reply-to: <3FCE2B59.50603@gnu.org> To: Andrew Cagney , Nitin Gupta Cc: Daniel Jacobowitz , Ian Lance Taylor , gdb@sources.redhat.com Reply-to: amitkale@emsyssoft.com Message-id: <200312051033.24058.kgdb@vsnl.net> Organization: EmSysSoft MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.5 References: <36993D449C7FA647BF43568E0793AB3E32A59B@nevis_pune_xchg.pune.nevisnetworks.com> <3FCE2B59.50603@gnu.org> X-SW-Source: 2003-12/txt/msg00104.txt.bz2 Hi, Making gdb handle multiple object images will be a lot of work. You can do something much simpler: Use multiple gdbs. You'll have to implement multiplexing of serial connections used by them. A small program that listens to tcp/ip sockets for gdb connections on one side and uses the hardware probe on the other. -- Amit Kale EmSysSoft (http://www.emsyssoft.com/) KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net) On Wednesday 03 Dec 2003 11:58 pm, Andrew Cagney wrote: > > Hi, > > How can GDB be used to debug an application running on a chip that has n > > number of similar CPUs. These CPUs share memories and run different code > > images. > > I plan to do a debugging session using the hardware probe and the GDB > > remote protocol. My target does not have any OS support as Linux or > > RTEMS but the host is a Linux box. > > My question is how can I get to know that currently GDB is talking to > > which CPU? Is it possible for me to do something like > > gdb> load image1.o > > gdb> CPU=1 > > gdb> |get register contents| > > gdb> load image2.o > > gdb> CPU=3 > > gdb> |get register contents| > > > > and such similar stuff. > > > > One way of implementing this is using the thread model but then each CPU > > has altogether different code image to execute. Shall I have multiple > > sessions of GDB, one per CPU? But again if a debug exception is raised > > say a breakpoint is hit, how will I know on the host side which CPU has > > hit the breakpoint. > > > > Has anybody done a similar task on any other target? Any help on this > > fron shall be grateful. > > CPU's can be modeled using GDB's thread framework. However, at present > the model doesn't extend as far as modeling separate memory regions for > each CPU (something that needs to be fixed). > > Andrew