aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--gdb/ChangeLog11
-rw-r--r--gdb/m68k-stub.c66
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 */