Re: GDB feature requests...

[Daniel Jacobowitz <drow@false.org>]

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