diff options
| -rw-r--r-- | gdb/ChangeLog | 11 | ||||
| -rw-r--r-- | gdb/m68k-stub.c | 66 |
2 files changed, 56 insertions, 21 deletions
diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 57fe7cc..ca53685 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,14 @@ +Tue Oct 26 15:07:29 1993 Jim Kingdon (kingdon@lioth.cygnus.com) + + * remote.c: Change PBUFSIZ back to 400. John's 28 Feb 1992 change + to increase it broke the ability to write large chunks of memory + with m68k-stub and i386-stub. Now we only use more than 400 on + machines where we need that much to write the registers. + * remote.c (remote_write_bytes): Eliminate possible abort(). The + check for when to abort was off by a few bytes and besides which, + it is handled by MAXBUFBYTES, which the caller uses. + * m68k-stub.c: Add comments about trap #1 and trap #8 instructions. + Tue Oct 26 08:36:07 1993 Doug Evans (dje@canuck.cygnus.com) * remote-sim.h (SIM_ADDR): New type (same as CORE_ADDR). diff --git a/gdb/m68k-stub.c b/gdb/m68k-stub.c index ae7553a..66398b3 100644 --- a/gdb/m68k-stub.c +++ b/gdb/m68k-stub.c @@ -13,28 +13,32 @@ ****************************************************************************/ /**************************************************************************** - * $Header$ + * Header: remcom.c,v 1.34 91/03/09 12:29:49 glenne Exp $ * - * $Module name: remcom.c $ - * $Revision$ - * $Date$ - * $Contributor: Lake Stevens Instrument Division$ + * Module name: remcom.c $ + * Revision: 1.34 $ + * Date: 91/03/09 12:29:49 $ + * Contributor: Lake Stevens Instrument Division$ * - * $Description: low level support for gdb debugger. $ + * Description: low level support for gdb debugger. $ * - * $Considerations: only works on target hardware $ + * Considerations: only works on target hardware $ * - * $Written by: Glenn Engel $ - * $ModuleState: Experimental $ + * Written by: Glenn Engel $ + * ModuleState: Experimental $ * - * $NOTES: See Below $ + * NOTES: See Below $ * * To enable debugger support, two things need to happen. One, a * call to set_debug_traps() is necessary in order to allow any breakpoints * or error conditions to be properly intercepted and reported to gdb. * Two, a breakpoint needs to be generated to begin communication. This * is most easily accomplished by a call to breakpoint(). Breakpoint() - * simulates a breakpoint by executing a trap #1. + * simulates a breakpoint by executing a trap #1. The breakpoint instruction + * is hardwired to trap #1 because not to do so is a compatibility problem-- + * there either should be a standard breakpoint instruction, or the protocol + * should be extended to provide some means to communicate which breakpoint + * instruction is in use (or have the stub insert the breakpoint). * * Some explanation is probably necessary to explain how exceptions are * handled. When an exception is encountered the 68000 pushes the current @@ -51,7 +55,7 @@ * The sole purpose of the routine _catchException is to compute the * exception number and push it on the stack in place of the return address. * The external function exceptionHandler() is - * used to attach a specific handler to a specific 68k exception. + * used to attach a specific handler to a specific m68k exception. * For 68020 machines, the ability to have a return address around just * so the vector can be determined is not necessary because the '020 pushes an * extra word onto the stack containing the vector offset @@ -121,7 +125,8 @@ extern ExceptionHook exceptionHook; /* hook variable for errors/exceptions */ /************************/ /* FORWARD DECLARATIONS */ /************************/ -void initializeRemcomErrorFrame(void); +static void +initializeRemcomErrorFrame (); /************************************************************************/ /* BUFMAX defines the maximum number of characters in inbound/outbound buffers*/ @@ -145,6 +150,15 @@ enum regnames {D0,D1,D2,D3,D4,D5,D6,D7, FPCONTROL,FPSTATUS,FPIADDR }; + +/* We keep a whole frame cache here. "Why?", I hear you cry, "doesn't + GDB handle that sort of thing?" Well, yes, I believe the only + reason for this cache is to save and restore floating point state + (fsave/frestore). A cleaner way to do this would be to make the + fsave data part of the registers which GDB deals with like any + other registers. This should not be a performance problem if the + ability to read individual registers is added to the protocol. */ + typedef struct FrameStruct { struct FrameStruct *previous; @@ -212,8 +226,8 @@ skip_frestore: \n\ #define RESTORE_FP_REGS() #endif /* __HAVE_68881__ */ -void return_to_super(void); -void return_to_user(void); +void return_to_super(); +void return_to_user(); asm(" .text @@ -277,7 +291,7 @@ asm(" lea sp@(4),sp"); /* pull off 68000 return address */ #endif asm(" rte"); -extern void _catchException(); +extern void _catchException (); #ifdef mc68020 /* This function is called when a 68020 exception occurs. It saves @@ -662,7 +676,13 @@ int exceptionVector; case 13: sigval = 8; break; /* floating point err */ case 31: sigval = 2; break; /* interrupt */ case 33: sigval = 5; break; /* breakpoint */ + + /* This is a trap #8 instruction. Apparently it is someone's software + convention for some sort of SIGFPE condition. Whose? How many + people are being screwed by having this code the way it is? + Is there a clean solution? */ case 40: sigval = 8; break; /* floating point err */ + case 48: sigval = 8; break; /* floating point err */ case 49: sigval = 8; break; /* floating point err */ case 50: sigval = 8; break; /* zero divide */ @@ -925,7 +945,8 @@ void handle_exception(int exceptionVector) } -void initializeRemcomErrorFrame(void) +void +initializeRemcomErrorFrame() { lastFrame = ((Frame *) &gdbFrameStack[FRAMESIZE-1]) - 1; lastFrame->previous = lastFrame; @@ -935,9 +956,9 @@ void initializeRemcomErrorFrame(void) breakpoints */ void set_debug_traps() { -extern void _debug_level7(); -extern void remcomHandler(); -int exception; + extern void _debug_level7(); + extern void remcomHandler(); + int exception; initializeRemcomErrorFrame(); stackPtr = &remcomStack[STACKSIZE/sizeof(int) - 1]; @@ -951,7 +972,10 @@ int exception; /* breakpoint exception (trap #1) */ exceptionHandler(33,_catchException); - /* floating point error (trap #8) */ + /* This is a trap #8 instruction. Apparently it is someone's software + convention for some sort of SIGFPE condition. Whose? How many + people are being screwed by having this code the way it is? + Is there a clean solution? */ exceptionHandler(40,_catchException); /* 48 to 54 are floating point coprocessor errors */ |