2011-12-14 Pedro Alves <pedro@codesourcery.com>

* gdb.texinfo (Implementing a Remote Stub): Explain that you
	should transfer control to the stub in the startup code instead of
	in main.  Mention the need to get past the initial breakpoint.
This commit is contained in:
Pedro Alves 2011-12-14 14:46:24 +00:00
parent ad32032e2e
commit 2fb860fcbc
2 changed files with 18 additions and 3 deletions

View File

@ -1,3 +1,9 @@
2011-12-14 Pedro Alves <pedro@codesourcery.com>
* gdb.texinfo (Implementing a Remote Stub): Explain that you
should transfer control to the stub in the startup code instead of
in main. Mention the need to get past the initial breakpoint.
2011-12-06 Tom Tromey <tromey@redhat.com>
* gdb.texinfo (Set Breaks): Update for new behavior.

View File

@ -17536,8 +17536,8 @@ subroutines:
@findex set_debug_traps
@cindex remote serial stub, initialization
This routine arranges for @code{handle_exception} to run when your
program stops. You must call this subroutine explicitly near the
beginning of your program.
program stops. You must call this subroutine explicitly in your
program's startup code.
@item handle_exception
@findex handle_exception
@ -17683,13 +17683,22 @@ Make sure you have defined the supporting low-level routines
@end display
@item
Insert these lines near the top of your program:
Insert these lines in your program's startup code, before the main
procedure is called:
@smallexample
set_debug_traps();
breakpoint();
@end smallexample
On some machines, when a breakpoint trap is raised, the hardware
automatically makes the PC point to the instruction after the
breakpoint. If your machine doesn't do that, you may need to adjust
@code{handle_exception} to arrange for it to return to the instruction
after the breakpoint on this first invocation, so that your program
doesn't keep hitting the initial breakpoint instead of making
progress.
@item
For the 680x0 stub only, you need to provide a variable called
@code{exceptionHook}. Normally you just use: