This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [WIP] TI msp430 CIO support


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]