Stub Contents

Go forward to Bootstrapping
Go up to remote stub
Go to the top op gdb

What the stub can do for you

The debugging stub for your architecture supplies these three
     This routine arranges for `handle_exception' to run when your
     program stops.  You must call this subroutine explicitly near the
     beginning of your program.
     This is the central workhorse, but your program never calls it
     explicitly--the setup code arranges for `handle_exception' to run
     when a trap is triggered.
     `handle_exception' takes control when your program stops during
     execution (for example, on a breakpoint), and mediates
     communications with GDB on the host machine.  This is where the
     communications protocol is implemented; `handle_exception' acts as
     the GDB representative on the target machine.  It begins by
     sending summary information on the state of your program, then
     continues to execute, retrieving and transmitting any information
     GDB needs, until you execute a GDB command that makes your program
     resume; at that point, `handle_exception' returns control to your
     own code on the target machine.
     Use this auxiliary subroutine to make your program contain a
     breakpoint.  Depending on the particular situation, this may be
     the only way for GDB to get control.  For instance, if your target
     machine has some sort of interrupt button, you won't need to call
     this; pressing the interrupt button transfers control to
     `handle_exception'--in effect, to GDB.  On some machines, simply
     receiving characters on the serial port may also trigger a trap;
     again, in that situation, you don't need to call `breakpoint' from
     your own program--simply running `target remote' from the host GDB
     session gets control.
     Call `breakpoint' if none of these is true, or if you simply want
     to make certain your program stops at a predetermined point for the
     start of your debugging session.