Re: [WIP] TI msp430 CIO support

[Kevin Buettner <kevinb@redhat.com>]

On Mon, 20 May 2013 08:38:59 -0600
Tom Tromey <tromey@redhat.com> wrote:

> >>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:
> 
> Kevin> The debugger based driver uses a simple breakpoint driven
> Kevin> implementation.  The debugger places a breakpoint on a known location
> Kevin> which is always called when debugger-based I/O is to be performed. 
> Kevin> When the breakpoint at that location is hit, the debugger reads the
> Kevin> details of the system call and its parameters from a memory based
> Kevin> buffer.  The debugger writes back the output of the system call to the
> Kevin> same buffer.  (See my patch for the exact details.)
> 
> I was also curious why this wasn't done on the stub side and just have
> the stub emit the output packets.

Doing it in the stub was our recommendation.  However, we didn't write
the stub and the party responsible for it wasn't willing to do it.

> Kevin> One of my early implementations of this functionality used a normal
> Kevin> (but hidden) GDB breakpoint with a command list whose last command
> Kevin> was "continue".  This is similar to the way that dprintf is implemented.
> 
> Another way is to have a hidden breakpoint and override its check_status
> breakpoint_ops method.  Then, have this method always set bs->stop = 0.
> 
> This won't work for dprintf, since dprintf wants various user-visible
> breakpoint tweaks to also work; but I think it would work fine for your
> case.

I'll give this a try.

Thanks,

Kevin