Re: proposed extension for jtag debugging

[Daniel Jacobowitz <drow at false dot org>]

On Mon, Jul 07, 2008 at 10:17:12PM +0100, Bart Veer wrote:
> These days gdb can interact with many hardware debug solutions based
> on jtag or BDM. Most solutions involve the remote protocol and a gdb
> server of some sort, including: OpenOCD, m68k-elf-sprite,
> nios2-gdb-server, and Abatron BDI units. There are exceptions, for
> example http://sourceforge.net/projects/bdm/ which adds a
> "target bdm" instead. Some solutions are open source, others are
> proprietary.

For the record, m68k-elf-sprite in that list supports the file-I/O
packets already.

> Now, in addition to 'O' packets gdb supports console I/O via the
> remote file I/O extension - as well as file I/O if desired. Hence one
> approach is to tweak remote-fileio.c so that it can be invoked even
> when the remote gdb server is not sending 'F' packets. The target-side
> code looks something like this:

It seems reasonable.  I would recommend a change, personally: avoid
working with strings.  There's an architecture method in GDB to tell
it the location of the first few pointer-sized arguments
(gdbarch_fetch_pointer_argument).  With this you could use the normal
file I/O structures.  It just means you need to add a "syscall number"
equivalent.

It's sad that you need to use the target strata for this.  Doing it
directly in the remote target would work for all of the above except
for "target bdm".  But I suppose it's reasonable.

> 1) is there any interest in adding functionality along these lines,
>    i.e. mostly portable console and host file I/O for jtag and BDM
>    debug solutions, to mainstream gdb?

Personally, we (CodeSourcery) add semihosting using the defined
protocol to every toolchain we touch.  I have neither interest nor
objection.

-- 
Daniel Jacobowitz
CodeSourcery