From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15034 invoked by alias); 10 Jun 2005 20:49:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14990 invoked by uid 22791); 10 Jun 2005 20:48:54 -0000 Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.194) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 10 Jun 2005 20:48:54 +0000 Received: by zproxy.gmail.com with SMTP id 40so972049nzk for ; Fri, 10 Jun 2005 13:48:52 -0700 (PDT) Received: by 10.36.115.15 with SMTP id n15mr611142nzc; Fri, 10 Jun 2005 13:48:50 -0700 (PDT) Received: by 10.36.221.70 with HTTP; Fri, 10 Jun 2005 13:48:50 -0700 (PDT) Message-ID: <7cb1293c050610134862dea814@mail.gmail.com> Date: Fri, 10 Jun 2005 20:49:00 -0000 From: Srinivas Murthy Reply-To: Srinivas Murthy To: Michael Snyder Subject: Re: gdb tool for multi-proc MIPS32 Cc: gdb-patches@sources.redhat.com In-Reply-To: <42A9FA20.20303@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7cb1293c05060810067a485e41@mail.gmail.com> <42A9FA20.20303@redhat.com> X-SW-Source: 2005-06/txt/msg00099.txt.bz2 Great suggestion. Thanks. I've been going over the gdb_internals doc on the web. For the target side, what would be a good starting point for me to put this together (for MIPS32)? Thanks, -Srinivas On 6/10/05, Michael Snyder wrote: > Srinivas Murthy wrote: > > Hi, > > We need to develop a gdb debug tool for a custom multi-processor MIPS > > target running in an infinite loop (without an OS) over a serial link > > with a UART. The host is an x86 machine with Linux OS. > > > > The single UART needs to provide connectivity to all the processors > > on the target and the debug tool needs to do processor specific > > commands (breakpoints, source-level debug, etc.). > > > > Can you guys please point me to any reference material, > > implementations, etc. for me to get started with this? >=20 > As far as what's in the official gdb source repository, > no one has ever done this, or anything like it. It's > likely that someone has done it outside of official gdb, > as a research or development project, and maybe even published > their results -- I wouldn't know. >=20 > But I have a suggestion for you, assuming you are doing > SIMD or something like it (all the processors running the > same instruction image). Pretend that your > processor cores are threads running under a single > processor. GDB knows how to deal with that. You must > have some sort of gdb "stub" or "agent" (like rda or > gdbserver) running on the target side -- just tell > that guy to interpret a thread id (from gdb) as a > processor id. "Give me this thread's registers" will > be interpreted as "give me this processor's registers". > Switching thread contexts will be interpreted as > switching processor contexts. >=20 > If you're not doing SIMD (ie. if your processors may > be running completely different code images), then > you'll probably have to debug each processor under a > separate gdb session, and multiplex their communications > onto your single uart somehow. >=20 >