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

[Bart Veer <bartv@ecoscentric.com>]

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

    >> >> >>> 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.

    <snip>
    
    Doug> My off-the-cuff thought is to see if this is something that
    Doug> could be handled from Python.
    >> 
    >> At a high-level you are correct: when a breakpoint is hit, call
    >> into the existing file I/O code and then automatically resume
    >> the target. However a usable implementation imposes some
    >> additional requirements. There should be no visible output
    >> every time some file I/O is requested, so no messages that the
    >> target has halted or that there has been a thread switch. The
    >> overheads must be kept down as much as possible, so no
    >> additional register fetching, no extra memory writes to unset
    >> and reset breakpoints, etc. I don't think that is achievable if
    >> you try to do the work at the command or scripting level.

    Doug> There are indeed issues to be resolved, but I'd like to
    Doug> think these things are achievable. We can provide lots more
    Doug> functionality this way, not just file i/o for jtag targets
    Doug> (and such).

    >> I have not been following the Python work, but as far as I know
    >> it does not allow scripts to operate at the target vector
    >> level. That could be useful for some things, for example it
    >> should make it possible to add thread support for different
    >> embedded OS'es by writing a script instead of adding a new
    >> module to gdb. I suspect it will be some time before anything
    >> like that is possible.

    Doug> I shouldn't be that hard to let Python work at this level,
    Doug> and AIUI such things are not precluded.

Although I have no doubt that a Python interface at the target vector
level is possible, figuring out what such an interface should look
like requires a far greater understanding of the gdb internals than I
possess. I am pretty sure it would also involve much bigger changes to
the internals than a one-line addition to the stratum enum. I really
don't want to see the h/w debug I/O functionality to be delayed for a
long time, possibly years, until all the required infrastructure is in
place for a reimplementation in Python.

Bart