From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4415 invoked by alias); 16 Jun 2008 14:14:52 -0000 Received: (qmail 4401 invoked by uid 22791); 16 Jun 2008 14:14:50 -0000 X-Spam-Check-By: sourceware.org Received: from chloe.misty.com (HELO smtpserver.misty.com) (198.137.254.134) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 16 Jun 2008 14:14:26 +0000 Received: from manx.misty.com (manx.misty.com [198.137.254.20]) by smtpserver.misty.com (8.13.8/8.13.8) with ESMTP id m5GEEO5X003133; Mon, 16 Jun 2008 10:14:24 -0400 (EDT) Received: from manx.misty.com (localhost [127.0.0.1]) by manx.misty.com (8.13.8+Sun/8.13.8) with ESMTP id m5GEEO0P009631; Mon, 16 Jun 2008 10:14:24 -0400 (EDT) Received: from localhost (hepler@localhost) by manx.misty.com (8.13.8+Sun/8.13.8/Submit) with ESMTP id m5GEENZd009628; Mon, 16 Jun 2008 10:14:24 -0400 (EDT) Date: Mon, 16 Jun 2008 14:14:00 -0000 From: "Edward L. Hepler" To: gdb@sourceware.org cc: hepler@vlsi-concepts.com Subject: GDB feature requests... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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/msg00158.txt.bz2 I have recently used GDB in a couple of ways that it was probably not designed to be used... I have a synthesizable core (MIPS variant) that I offer that is intended for embedded control. I wanted to use GDB in four different steps along the development process. The four steps are: 1. Driving a standalone simulator. The simulator is cycle accurate and each call to the simulator "function" causes a single cycle to be executed. This is partially supported by GDB. The simulator is purely software and GDB is the driver (meaning that the user interacts through GDB and GDB "causes" cycles to be initiated.) 2. Simulating the core while it is embedded in an RTL simulation. An RTL simulator simulates the system being developed. The processor is modelled using the cycle correct (software) simulator with a wrapper (FLI or PLI) that allows it to be inserted into the RTL. Here GDB acts as an interface to the processor, but does not drive the simulation (this is done by the RTL simulator). GDB allows the SW developer to debug code that is running in the simulated system environment. 3. This is similar to step 2, but the "real" RTL for the processor is used in the system simulation mode instead of the SW simulation (properly wrapped) model of the processor. GDB is still used to allow SW developers to monitor the state of SW in the simulated system. The biggest difference here (compared to #2) is the way in which GDB gains access to the internal state of the processor registers, etc. The RTL has a JTAG interface, but this is too slow for simulation purposes, so a short cut is provided for GDB through the simulator. Again, the simulator is really in control of advancing the clock. 4. Monitoring the core while in the real system. Here the core has been instantiated in a system and is implemented in an FPGA or ASIC. Access to the process internals is via a JTAG cable. GDB controls the actions of the processor... Getting GDB to deal with these modes was trying at times and some of the solutions that I came up with are far from optimal. Some of the issues may be my mis-understanding of how GDB does things. Some of this may be due to (my perception) of a lack of documentation when it comes to porting GDB to a new target. In my case, the processor core is to be used in an embedded system. Due to the nature of embedded systems, having a "process" running on the target to intercept serial commands and provide info back to GDB is not always possible (and adds unwanted overhead on the target). I added an interface to GDB (really modified one of the existing targets) to provide a JTAG interface. This interface is rather primative, but seems to provide the necessary info for GDB. 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. Some of what I am requesting may already be there, but my lack of GDB knowledge may be getting in the way... Things I would like to see: 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. 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). 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. I haven't thought a lot about this, but having the GDB functionality be "callable" might be interesting. When used in the traditional mode (user interface debugging a resident program), a user interface layer would simply call the GDB functionality. When working in an embedded simulation mode, the simulator could call GDB functionality when the simulator stops (for whatever reason). I have been using ModelSim, but would like to be able to handle any RTL simulator. 4. Better documentation on the 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... Thanks, Ed Hepler ---------------------------------------------------------------------------- VLSI Concepts offers synthesizable processor cores for embedded control applications... See our standard products and ask about customization... ---------------------------------------------------------------------------- Dr. Edward L. Hepler President, Adjunct Professor, VLSI Concepts, Inc. Villanova University Graduate Courses: VLSI and System ECE-8440 System Design and Modeling Architecture, Design, ECE-8445 Advanced Computer Architecture and CAD ECE-8460 VLSI Design email: hepler@vlsi-concepts.com or elh@ece.villanova.edu www: http://www.vlsi-concepts.com Read: I Cor 8:6