From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12567 invoked by alias); 31 Jul 2003 22:36:31 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12542 invoked from network); 31 Jul 2003 22:36:28 -0000 Received: from unknown (HELO mail.inka.de) (193.197.184.2) by sources.redhat.com with SMTP; 31 Jul 2003 22:36:28 -0000 Received: from raven.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 19iM27-00006U-00; Fri, 01 Aug 2003 00:36:27 +0200 Received: from localhost (localhost [127.0.0.1]) by raven.inka.de (Postfix) with ESMTP id 1F7B01B7 for ; Fri, 1 Aug 2003 00:35:19 +0200 (CEST) Received: by raven.inka.de (Postfix, from userid 500) id 388D11BF; Fri, 1 Aug 2003 00:35:14 +0200 (CEST) Date: Thu, 31 Jul 2003 22:36:00 -0000 From: Josef Wolf To: gdb@sources.redhat.com Subject: Need Help for bringing m68k-based bdm target-patches form gdb-5.2.1 to gdb-5.3 Message-ID: <20030731223514.GD20282@raven.inka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS snapshot-20020531 X-SW-Source: 2003-07/txt/msg00390.txt.bz2 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 --