This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
GDB feature requests...
- From: "Edward L. Hepler" <hepler at vlsi-concepts dot com>
- To: gdb at sourceware dot org
- Cc: hepler at vlsi-concepts dot com
- Date: Mon, 16 Jun 2008 10:14:23 -0400 (EDT)
- Subject: GDB feature requests...
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