This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [WIP] TI msp430 CIO support
- From: Kevin Buettner <kevinb at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Tue, 21 May 2013 09:00:45 -0700
- Subject: Re: [WIP] TI msp430 CIO support
- References: <20130516212358 dot 23f3bcdb at mesquite dot lan> <87ip2dogvw dot fsf at fleche dot redhat dot 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