Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* m68k multi-arch problems
@ 2002-06-21 14:51 Aaron J. Grier
  2002-06-21 17:31 ` Andrew Cagney
  0 siblings, 1 reply; 2+ messages in thread
From: Aaron J. Grier @ 2002-06-21 14:51 UTC (permalink / raw)
  To: gdb-patches

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.

can anybody spare me a clue?

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron@frye.com


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: m68k multi-arch problems
  2002-06-21 14:51 m68k multi-arch problems Aaron J. Grier
@ 2002-06-21 17:31 ` Andrew Cagney
  0 siblings, 0 replies; 2+ messages in thread
From: Andrew Cagney @ 2002-06-21 17:31 UTC (permalink / raw)
  To: Aaron J. Grier, Grace Sainsbury; +Cc: gdb-patches

[-- 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 */

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-06-22  0:31 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-21 14:51 m68k multi-arch problems Aaron J. Grier
2002-06-21 17:31 ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox