GDB feature requests...

["Edward L. Hepler" <hepler at vlsi-concepts dot com>]

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