From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18048 invoked by alias); 16 Jun 2008 14:47:31 -0000 Received: (qmail 18035 invoked by uid 22791); 16 Jun 2008 14:47:30 -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.31) with ESMTP; Mon, 16 Jun 2008 14:47:10 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 61D159840F; Mon, 16 Jun 2008 14:47:08 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 3E7D79840B; Mon, 16 Jun 2008 14:47:08 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1K8Fz9-00057D-4m; Mon, 16 Jun 2008 10:47:07 -0400 Date: Mon, 16 Jun 2008 14:47:00 -0000 From: Daniel Jacobowitz To: "Edward L. Hepler" Cc: gdb@sourceware.org Subject: Re: GDB feature requests... Message-ID: <20080616144707.GA19077@caradoc.them.org> Mail-Followup-To: "Edward L. Hepler" , gdb@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-06/txt/msg00159.txt.bz2 On Mon, Jun 16, 2008 at 10:14:23AM -0400, Edward L. Hepler wrote: > It appears that GDB really only needs to access the following information > to successfully operate: > > 1. Read / Write general and special registers within the target processor > 2. Read / Write memory (both instruction and data in harvard > architectures) > 3. Detect when the processor has hit a breakpoint (in my case, a special > instruction that puts the core into debug (JTAG access) mode). > 4. Start the processor (take it out of debug mode). Single stepping can > be accomplished by appropriately setting the SW breakpoints. Correct, although there are some other things which can be useful (like watchpoints). SW breakpoint based single-step works, but hardware single step is superior; it interferes with program behavior less and is faster. > 1. More modular target interface. I think this may be there, but it > doesn't appear to be consistent... Try to get all GDB functionality > to use low level read register, write register, read memory, etc. > Having the register definitions be table driven may be more useful. > Having direct support for multiple memory spaces (I and D) may be > useful. These low level access requests can then be mapped to > the serial interface (for use when there is a monitor running on > the target), the JTAG interface, the simulator interface, etc. What specific problems did you have? Nothing in GDB outside the target interface (target_ops) knows how to access the target, so this is clearly already the case. I/D space is tricky :-( GDB supports it today, but only via having internal "addresses" be larger than target pointers. For instance, reserving one bit of the address to differentiate between I and D spaces. In general GDB needs to agree with the convention used by your tools; ELF does not include address space markers either. > 2. Better documentation on the target interface (for things that may > already be there that I didn't find while searching through the code). > I have done this for a MIPS variant and for a synthesizable 68000... > I would like to be able to generate the interface for any of my > synthesizable cores more quickly (and consistently). My usual answer to this, and to your first point, is "use the remote serial protocol". This lets you write your simulators - or JTAG layer - as a separate process. It can listen on a TCP socket or communicate over standard input / output with the recent "target remote |" command. It's completely modular and well documented; and the protocol itself is not particularly complicated. > 3. More modular operational interface. Right now, it appears that GDB > always wants to be in control... When trying to "attach" GDB to > a processor that is being modelled in another simulator, this is not > always the case... One of my "solutions" is to have a process that > polls between GDB and the RTL simulator... It works, but uses way too > many (host) cpu cycles. It solves this, too; the communication layer goes in your simulator. > 4. Better documentation on the operational interface. Sorry, I don't know what you mean by operational interface. > 5. I haven't tried this yet, but I want to be able to attach two (or > more) copies of GDB to multiple instances of the processor core in > a single system simulation. On the surface, this should not be too > much of a problem, but I would also like to have some way of informing > the "other" GDB that the first has hit a breakpoint and the status of > the processor should be determined... This is one of two widely considered options for multi-processor support. As long as you don't want cross-triggering between the two debuggers, it works well with the remote protocol approach, although the protocol layer in your simulator/JTAG-gateway becomes more complex. The other approach, a hybrid GDB which supports multiple asynchronously executing targets, is being actively worked on today. CodeSourcery's been contributing patches for both multi-process (multiple distinct programs executing on your target, or eventually multiple asymmetric cores) and non-stop (usable debugger while some attached threads/processes/cores are still running) support. Hope that helps! -- Daniel Jacobowitz CodeSourcery