Re: m68k multi-arch problems

[Andrew Cagney <ac131313@cygnus.com>]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

> the latest round of m68k multi-arch patches seems to have broken things
> for the m68k-rtems target.
> 
> valops.c won't compile due to missing POP_FRAME, which used to be
> defined unconditionally in tm-m68k.h...
> 
> I couldn't easily divine where it's supposed to be defined now, or where
> GDB_MULTI_ARCH_PARTIAL is supposed to be turned off.

Looks like a tipo.

> can anybody spare me a clue?

Hmm, I suspect NorthOfA have gone home for the weekend, I've committed 
the attached - it gets past the immediate build problem.

Andrew


[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1760 bytes --]

2002-06-21  Andrew Cagney  <ac131313@redhat.com>

	* config/m68k/tm-m68k.h: Fix typo.
	(FRAME_INIT_SAVED_REGS): Define when non-multi-arch.
	(m68k_frame_init_saved_regs): Declare.

Index: config/m68k/tm-m68k.h
===================================================================
RCS file: /cvs/src/src/gdb/config/m68k/tm-m68k.h,v
retrieving revision 1.14
diff -u -r1.14 tm-m68k.h
--- config/m68k/tm-m68k.h	21 Jun 2002 20:23:29 -0000	1.14
+++ config/m68k/tm-m68k.h	21 Jun 2002 23:40:55 -0000
@@ -298,6 +298,19 @@
 /* Return number of bytes at start of arglist that are not really args.  */
 
 #define FRAME_ARGS_SKIP 8
+
+/* Put here the code to store, into a struct frame_saved_regs,
+   the addresses of the saved registers of frame described by FRAME_INFO.
+   This includes special registers such as pc and fp saved in special
+   ways in the stack frame.  sp is even more special:
+   the address we return for it IS the sp for the next frame.  */
+
+#if !GDB_MULTI_ARCH
+#if !defined (FRAME_INIT_SAVED_REGS)
+#define FRAME_INIT_SAVED_REGS(fi) m68k_frame_init_saved_regs ((fi))
+void m68k_frame_init_saved_regs (struct frame_info *frame_info);
+#endif /* no FRAME_INIT_SAVED_REGS.  */
+#endif
 \f
 
 /* Things needed for making the inferior call functions.  */
@@ -331,7 +344,7 @@
 /* FIXME: Wrong to hardwire this as BPT_VECTOR when sometimes it
    should be REMOTE_BPT_VECTOR.  Best way to fix it would be to define
    CALL_DUMMY_BREAKPOINT_OFFSET.  */
-#if !GDB_MULTI_ARCH_PARTIAL
+#if !GDB_MULTI_ARCH
 #define CALL_DUMMY {0xf227e0ff, 0x48e7fffc, 0x426742e7, 0x4eb93232, 0x3232dffc, 0x69696969, (0x4e404e71 | (BPT_VECTOR << 16))}
 #define CALL_DUMMY_LENGTH 28	/* Size of CALL_DUMMY */
 #define CALL_DUMMY_START_OFFSET 12	/* Offset to jsr instruction */