GDB feature requests...

GDB feature requests...

[Edward L. Hepler]

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

Re: GDB feature requests...

[Daniel Jacobowitz]

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