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

[Bart Veer <bartv at ecoscentric dot 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.
    
    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?

    Bart> The rationale was given in
    Bart> http://sourceware.org/ml/gdb/2008-07/msg00045.html
    >> 
    >> <snip>
    >> 
    >> Just wondering if you had had a chance to take another look at this.
    >> It has now been six weeks since the original posting.

    Doug> Hi. fwiw, I've read the patch and past emails. fwiw, I love
    Doug> the idea but wonder if it should be done differently. Adding
    Doug> a new stratum feels wrong to me too. But maybe I'm missing
    Doug> something so let me first ask a question. Basically all you
    Doug> need is a way to run some special code when a particular
    Doug> breakpoint is hit, right? [There's some housekeeping like
    Doug> needing to intercept program loads (IIRC), but basically the
    Doug> high order bit is running special code when a particular
    Doug> breakpoint is hit, right?] I'm just wondering if this can be
    Doug> done differently without being as invasive on GDB's innards.
    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.

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.

Bart

--
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
 ** Visit us on stand 905 at the Embedded Systems Show 2008 **
 ** Oct 1-2, NEC, Birmingham, UK http://www.embedded.co.uk  **