From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1266 invoked by alias); 2 Aug 2003 01:37:35 -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 1236 invoked from network); 2 Aug 2003 01:37:34 -0000 Received: from unknown (HELO mms3.broadcom.com) (63.70.210.38) by sources.redhat.com with SMTP; 2 Aug 2003 01:37:34 -0000 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Fri, 01 Aug 2003 18:37:18 -0700 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA17803; Fri, 1 Aug 2003 18:36:41 -0700 (PDT) Received: from ldt-sj3-010.sj.broadcom.com (ldt-sj3-010 [10.21.64.10]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id h721b6ov006169; Fri, 1 Aug 2003 18:37:06 -0700 (PDT) Received: (from cgd@localhost) by ldt-sj3-010.sj.broadcom.com ( 8.11.6/8.9.3) id h721b6u25605; Fri, 1 Aug 2003 18:37:06 -0700 X-Authentication-Warning: ldt-sj3-010.sj.broadcom.com: cgd set sender to cgd@broadcom.com using -f To: ac131313@redhat.com cc: gdb@sources.redhat.com Subject: Re: Next for GDB References: <3F2AFBD5.3040708@redhat.com> From: cgd@broadcom.com Date: Sat, 02 Aug 2003 01:37:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-WSS-ID: 1335CA44728375-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00033.txt.bz2 Is today Scary Andrew Mail Day? 8-) At Fri, 1 Aug 2003 23:47:12 +0000 (UTC), "Andrew Cagney" wrote: > [ ... ] My curent TODO list for gdb includes > > [ ... ] > - the sim vector What's on your to-do list there? If there's going to be much work on the interface to the simulator, one thing that *should* be implemented IMO is some mechanism to allow multiple processors in a simulator to be exposed to GDB, probably using some thread-related mechanism. I've not looked into GDB's thread bits for about a year and a half, i don't recall if it splits the notion of 'user thread' vs. 'kernel context' (i.e., M and N in MxN threading systems) or tries to make any such distinction. Multiple cores would kind-of correspond to multiple kernel contexts... i've got a year and a half old diff that starts adapting some old version of GDB (5.2?) to support multiple cores/threads under simulation, if somebody wants it. (in order to support debugging multiple cores in our gdb+simulator -- again a plug for http://sibyte.broadcom.com/public/resources/#tools -- we currently use a fairly nasty but functional hack. I started to try to fix that, but then that business trip ended and lack of productivity resumed.) cgd