This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [WIP] TI msp430 CIO support
- From: Tom Tromey <tromey at redhat dot com>
- To: Kevin Buettner <kevinb at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 20 May 2013 08:38:59 -0600
- Subject: Re: [WIP] TI msp430 CIO support
- References: <20130516212358 dot 23f3bcdb at mesquite dot lan>
>>>>> "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.
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.
Tom