Re: Breakpoint Handling in GDB

[Michael Snyder <Michael dot Snyder at palmsource dot com>]

On Wed, 2006-08-30 at 15:40 +0200, Veenu Verma (AS/EAB) wrote:
> Hello
> I was going through the gdb internals on software breakpoint handling
> and have a question regarding that.
> Gdb replaces the program instruction with a trap which means target does
> not have any control over setting a bp.
> What happens if the connection with the gdb breaks down ? 
> Does it mean that the illegal instruction won't be restored and the
> application will crash ?

In the general case, yes, that's what it means.

> If that's the case, then how can it be handled ? 

The newer z0/Z0 remote commands will allow the target debug agent
(eg. gdbserver) to handle the breakpoints.  But if you're using the
original method of breakpointing by writing trap instructions into
target memory, then yes, you're vulnerable to the scenario that you
describe.

If you can't reboot the target, you MIGHT try re-connecting with
gdb, and "fixing" the trap instructions by hand.  Obviously this 
is "at your own risk".  GDB does not have any built-in capability
to help with the situation that you describe.

However, I *have* used the following method:

1) If possible, get the locations of the breakpoints using
gdb's "info break" command.
2) WITHOUT reconnecting to the target, load the target's 
executable file into gdb, and examine (and record) the contents 
of memory at those locations, eg. like this:
	(gdb) print /x *(unsigned int *) 0xabcdef

3) Now reconnect to the target, and modify those locations
to match what's in the original binary file, eg.:
	(gdb) set *(unsigned int *) 0xabcdef = <value>

Again, YMMV, use at your own risk, operators are trained 
professionals etc. etc.

Remember, there may be trap instructions that you don't know about, 
eg. if you were in the middle of a "next" or "finish" when you lost
communication with the target.