From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16771 invoked by alias); 25 Nov 2008 04:06:44 -0000 Received: (qmail 16714 invoked by uid 22791); 25 Nov 2008 04:06:43 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 25 Nov 2008 04:06:04 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id F15E910D50; Tue, 25 Nov 2008 04:05:53 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id C4D3910AD3; Tue, 25 Nov 2008 04:05:53 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1L4pBQ-0007vb-W6; Mon, 24 Nov 2008 23:05:52 -0500 Date: Tue, 25 Nov 2008 04:06:00 -0000 From: Daniel Jacobowitz To: Duane Ellis Cc: gdb@sourceware.org Subject: Re: GDB for multiple targets Message-ID: <20081125040552.GA30147@caradoc.them.org> Mail-Followup-To: Duane Ellis , gdb@sourceware.org References: <492AD78E.4040905@duaneellis.com> <20081124220204.GA8666@caradoc.them.org> <492B40D9.8050703@duaneellis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <492B40D9.8050703@duaneellis.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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: 2008-11/txt/msg00149.txt.bz2 On Mon, Nov 24, 2008 at 07:03:37PM -0500, Duane Ellis wrote: > (1) In the case of OpenOCD - nothing ensures the *openocd.cfg* file > matches what the *EXE*FILE* says and/or the actual hardware target found > via jtag. My goal wold be reporting up information so at a minimum some > warning message could be printed. Yes, we already do generate such warnings. You have to generate an architecture element in the description to get that behavior though. > (2) In the arm micro controller "bare-metal-world" - the OSABI is often > not used or is generic, example: arm-elf - is a generic widely used > configuration that does not report the actual OS being used. arm-elf is not an OSABI, it's a target triplet. The usual OSABI for it is "none". GDB doesn't support dynamic registration of new OSABIs, but it could probably be implemented. > Many embedded debuggers have the ability to display on-chip registers, > ie: The MicroChip IDE for PIC32 (a mips m4K cpu, via GCC) has displays > for UART, TIMERS, GPIO. > > GDB Front Ends (ie: Eclipse, insight) could also display this type of > information - if - it had details about the chip. The way to do this is not by chip name but by the rest of the target description language. We're already doing that at CodeSourcery. > (5) One other road block today - is while GDB can fetch this > information. I know of no command in GDB to pass the "target.xml" up the > food chain to the front end (ie: eclipse, insight) > > Maybe a command like: "targetxmlfetch 'target.xml'" is needed? > > (6) Same could be said about the "memorymap.xml" Right. Patches welcome. > None of us are *today* in the position to make all of these things > happen. I beg to differ. There's no chicken and egg problem. I and others have spent the past several years adding this sort of feature to GDB for the same reasons you describe and we're already doing things with GDB that the GDB of several years ago couldn't come close to. When you need things that we haven't added already, you're more than welcome to contribute :-) But please see about an FSF copyright assignment if you plan to do that; I can help you with that if you don't have one yet. -- Daniel Jacobowitz CodeSourcery