Need Help for bringing m68k-based bdm target-patches form gdb-5.2.1 to gdb-5.3

[Josef Wolf <jw at raven dot inka dot de>]

Hello folks!

(This mail got somewhat lengthy. Sorry for that. But I am trapped withhin
gdb internals and cant see the exit :)

The story began as I started to bring the bdm-patches for the motorola
cpu32 (which is m68k-based) up to the current gdb-5.3 release. If anyone
is curious what those patches are about, they are available at
http://cmp.felk.cvut.cz/~pisa/m683xx/gdb-5.2.1-bdm-patches-pi1.tar.gz
They are based on gdb-5.2.1.

Needless to say that the patches did not work with gdb-5.3. Too much
restructuring was done from gdb-5.2.1 up to gdb-5.3. So I did a
binary search through the CVS-checkins to identify the checkin on
which they stopped working. It turned out that they stopped working
after the checkin from Andrew Cagney at "2002-06-08 18:57 UTC".
The relevant change was that default_get_saved_register() was deleted
and replaced with generic_unwind_get_saved_register()

The problem with this replacement was that default_get_saved_register()
semantically did

     if (frame==NULL)
         *addrp=REGISTER_BYTE(regnum);

while generic_unwind_get_saved_register() semantically did

     if (frame==NULL)
         *addrp=0;

This confused value_of_register() because it stores this address into
the value struct, so that callers can calculate the register number from
this address. This results in clobbering of all the register contents of
the target because everything seemed to be in register 0.

This little patch (which is relative to the cvs version
 -D "2002-06-08 19:00 UTC") fixed that problem:

----------snip---------
diff -ud gdb/gdb/frame.c gdb.patched/gdb/frame.c
--- gdb/gdb/frame.c  2003-07-29 15:42:37.000000000 +0200
+++ gdb.patched/gdb/frame.c     2003-07-30 15:00:37.000000000 +0200
@@ -150,6 +150,8 @@
   else
     frame_register_unwind (frame->next, regnum, optimizedp, lvalp, addrp,
 			   &realnumx, raw_buffer);
+
+  if (*addrp == 0) *addrp = REGISTER_BYTE (regnum);
 }
 
 void
----------snip---------

This leads to my first set of questions: Is my understanding about the
problem correct? Or should the bdm patches be changed to provide a
different way to get the value of the registers?


But the never ending story goes on: After applying this patch, I went ahead.
Again, the bdm-patch stopped working after the checkin from Grace Sainsbury
at -D "2002-07-02 18:13 UTC" which introduced GDB_MULTI_ARCH_PARTIAL into
the m68k-based targets. This time, the following patch fixed the problem:

----------snip---------
diff -urd gdb/gdb/config/m68k/tm-m68k.h gdb.patched/gdb/config/m68k/tm-m68k.h
--- gdb/gdb/config/m68k/tm-m68k.h	2003-07-31 18:14:59.000000000 +0200
+++ gdb.patched/gdb/config/m68k/tm-m68k.h	2003-07-31 18:22:32.000 +0200
@@ -21,7 +21,7 @@
 
 #include "regcache.h"
 
-#define GDB_MULTI_ARCH GDB_MULTI_ARCH_PARTIAL
+#define GDB_MULTI_ARCH 0
 
 /* Generic 68000 stuff, to be included by other tm-*.h files.  */
 
diff -urd gdb/gdb/m68k-tdep.c gdb.patched/gdb/m68k-tdep.c
--- gdb/gdb/m68k-tdep.c	2003-07-31 18:15:46.000 +0200
+++ gdb.patched/gdb/m68k-tdep.c	2003-07-31 18:21:56.00 +0200
@@ -60,14 +60,14 @@
   E_SP_REGNUM = 15,		/* Contains address of top of stack */
   E_PS_REGNUM = 16,		/* Contains processor status */
   E_PC_REGNUM = 17,		/* Contains program counter */
-  E_FP0_REGNUM = 18,		/* Floating point register 0 */
+  E_FP0_REGNUM = 26,		/* Floating point register 0 */
   E_FPC_REGNUM = 26,		/* 68881 control register */
   E_FPS_REGNUM = 27,		/* 68881 status register */
   E_FPI_REGNUM = 28
 };
 
-#define REGISTER_BYTES_FP (16*4 + 8 + 8*12 + 3*4)
-#define REGISTER_BYTES_NOFP (16*4 + 8)
+#define REGISTER_BYTES_FP (16*4 + 8 + 9*4 + 8*12 + 3*4)
+#define REGISTER_BYTES_NOFP (16*4 + 8 + 9*4 + 8*12 + 3*4)
 
 #define NUM_FREGS (NUM_REGS-24)
 
----------snip---------

That is, there are two problems. First is that the bdm-enabled target have
some additional registers. Those registers are

  "pcc", "usp", "ssp", "sfc", "dfc", "atemp", "far", "vbr",

which are placed between "pc" and "fp0". Most of those registers are
standard m68k registers, so I wonder how E_FP0_REGNUM can be set to 18?
Could it be that the bdm-patches have a broken register mapping? Or is
it that gdb dont want to know anything about vbr, ssp, sfc etc/pp?

The second problem is that I have disabled the MULTI_ARCH configuration.
If I understand correctly, you gdb-gurus want to go towards MULTI_ARCH.
So it would be silly if I would not try to go along with you into the
MULTI_ARCH direction. But I must confess that I have no clue what the
requirements are for that.


Currently, I can successfully build and run cvs snapshot from 2002-07-09.
AFAICS, frame handling changed very much from 2002-07-09 up to gdb-5.3.
So I expect a lot of additional hurdles on this way. And I am not sure
whether I will be able to take those hurdles without some helping hand.
So please, if anybody can give me some hints, they will be welcome :)

Thanks!

-- 
Please visit and sign http://petition-eurolinux.org and http://www.ffii.org
-- Josef Wolf -- jw@raven.inka.de --