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

["Doug Evans" <dje@google.com>]

On Wed, Sep 24, 2008 at 2:20 PM, Bart Veer <bartv@ecoscentric.com> wrote:
>>>>>> "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.

There are indeed issues to be resolved, but
I'd like to think these things are achievable.
We can provide lots more functionality this way, not just file i/o
for jtag targets (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.

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