This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB feature requests...
- From: Daniel Jacobowitz <drow at false dot org>
- To: "Edward L. Hepler" <hepler at vlsi-concepts dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 16 Jun 2008 10:47:07 -0400
- Subject: Re: GDB feature requests...
- References: <Pine.GSO.4.62.0806160922090.8018@manx.misty.com>
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