Re: add file I/O support when debugging an embedded target via jtag

[Bart Veer <bartv@ecoscentric.com>]

>>>>> "Stan" == Stan Shebs <stan@codesourcery.com> writes:

    Stan> Bart Veer wrote:
    >> Following on from
    >> http://sourceware.org/ml/gdb-patches/2008-08/msg00315.html, I have not
    >> heard anything about the code in the last two weeks. Do you know if
    >> anybody is looking at it? Also, if there is a likelihood that the
    >> patch will be accepted then I should probably get started on the
    >> assignment paperwork.

    Stan> To be honest, I looked at it but didn't understand why all
    Stan> this stuff seemed necessary. If this is not for the remote
    Stan> protocol, then what is it for? A target supported by GDB, or
    Stan> something else?

The rationale was given in
http://sourceware.org/ml/gdb/2008-07/msg00045.html
The remote protocol file I/O extensions work fine when gdb interacts
with target-side stub code over a serial line or ethernet, since
target-side code can send the requests to gdb.

Now consider a typical setup involving jtag. gdb does not access the
jtag unit directly. Instead it uses the remote protocol to interact
with a server of some kind over TCP, and the server controls the jtag
unit. Examples of this include OpenOCD, m68k-elf-sprite,
nios2-gdb-server, ... Some are open source, others are proprietary.
Target-side code has no portable way of requesting that the jtag
server sends a file I/O request to gdb. Some of these servers may
implement their own file I/O mechanisms, but that does not give a
portable solution.

The purpose of the patch is to provide portable support for file I/O
independent from the jtag server being used. In fact it should also
work with targets that do not involve the remote protocol, e.g.
simulators, although I confess I have not tried that.

    Stan> The addition of another stratum raises alarm bells with me,
    Stan> because the stratums are not as orthogonal as they should
    Stan> be, and I wouldn't be surprised if other configurations were
    Stan> broken by this.

I did not see any alternative. The h/w debug file I/O code has to
sit at a higher stratum than process_stratum (e.g. remote_ops) since
it has to override that stratum's resume/wait/load operations. It
should also sit at a level lower than thread_stratum. The file I/O
support is independent from the specific embedded OS or run-time being
used, but thread support for each OS will not be quite so portable. I
did consider putting the code into remote.c and thus explicitly tying
it to the remote protocol and remote_ops, but that would make it
impossible to use the functionality with e.g. a simulator.

For existing configurations there really should not be any change in
behaviour since there won't be any target ops at
process_override_stratum. The numerical value associated with
thread_stratum will have incremented by one, but I would hope that
there is no code anywhere assuming that thread_stratum==4.

    Stan> Also, how will everybody regression-test this (read: "make
    Stan> check") to know that other changes haven't broken this code?

A fair point. I am not really familiar with the capabilities of the
gdb testsuite, but the obvious problem here is on the target-side. In
due course the h/w debug file I/O support may be integrated to a
greater or lesser extent into various embedded OS's, so you cannot
just take the example code in doc/hwdebug-example.c and turn it into a
testcase: you would have both the OS and the testcase trying to define
_gdb_hwdebug_breakpoint.

Bart