From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12174 invoked by alias); 25 Apr 2005 13:05:02 -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 11955 invoked from network); 25 Apr 2005 13:04:41 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 25 Apr 2005 13:04:41 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DQ3GT-0001xx-6T; Mon, 25 Apr 2005 09:04:41 -0400 Date: Mon, 25 Apr 2005 18:49:00 -0000 From: Daniel Jacobowitz To: "Decker, Paul" Cc: gdb@sources.redhat.com Subject: Re: gdb port project Message-ID: <20050425130441.GB7316@nevyn.them.org> Mail-Followup-To: "Decker, Paul" , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00175.txt.bz2 On Fri, Apr 22, 2005 at 01:30:06PM -0400, Decker, Paul wrote: > > > > Hello everyone, > > We've been considering a port of gdb to support a new processor. A > couple of implementation specific questions seem to come to mind and I > was curious if anyone had any ideas on these: > > 1. The gdb port would consist of the gdb application and a gdb > proxy(server) which would connect to a custom ICE. The gdb proxy has a > list of registers for the specific processor which are in a specific > order. The gdb application also will have a list of registers. Is > there a way to insure these register lists are in 'sync' with each > other, for example if an older version of the gdb proxy were used with a > newer gdb which supported more registers, or registers in a different > order. This question could also be extended to include a basic gdb > connecting to a proxy which supported multiple derivatives of the same > processor, perhaps with a different feature set. > > One thought I had was to extend the gdb debugger to ask, on startup, the > proxy how many registers it supported, what their names were, and what > order they were in. GDB doesn't currently support anythin like that. But, I think it will soon; I have a prototype implementation which is pretty similar to what you describe. I just need to find the time to propose it properly. Normally you just define a register mapping, and make sure to add new registers at the end. > 2. I've searched around for multi-processing support within gdb, and I > don't see much in the way of supporting debugging multi-processor > systems. Specifically, if a processor has multiple cores, is there any > standard convention for gdb to support this? > > My initial idea was to have the proxy & ice support the multi cores, and > have the ability of two instances of gdb to be started, the first > instance would connect over tcp to port n, the second instance would > connect to the second core on port n+1. This way, 1 to n multi-cores > could be debugged and controlled. The downside is that there are no > native multi-processor commands in gdb, for example, a run would cause a > specific core to start running. There isn't a method of issuing a 'run > all' or a 'run group' to cause all the cores to or a group of cores to > start running. In general, you use a single GDB and a single stub. You present the multiple cores as threads of a single program. Anything missing in GDB for dealing with multiple cores is likely to be missing for dealing with threads, too; the models are very similar. -- Daniel Jacobowitz CodeSourcery, LLC