From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27469 invoked by alias); 6 Aug 2003 16:09:55 -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 27451 invoked from network); 6 Aug 2003 16:09:53 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 6 Aug 2003 16:09:53 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D763A2B7F; Wed, 6 Aug 2003 12:09:40 -0400 (EDT) Message-ID: <3F312844.9000308@redhat.com> Date: Wed, 06 Aug 2003 16:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josef Wolf , schwab@suse.de Cc: gdb@sources.redhat.com Subject: Re: Need Help for bringing m68k-based bdm target-patches form gdb-5.2.1 to gdb-5.3 References: <20030731223514.GD20282@raven.inka.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00077.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; Yes, your analysis here is correct. I believe it's been fixed in current sources though. Both frame.c:frame_register and sentinel-frame.c:sentinel_frame_prev_register correctly are setting the register's offset. (and GDB is desperatly wants to eliminate that hack). > 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? [I'm guessing here] The bdm code should use supply_register(REGNUM, BUF). If it is still using the [deprecated_]registers array then it will first need to be updated so that it instead uses supply_register / collect_register. With that done, the code's dependency on the raw register buffer layout should have been eliminated. That should in turn make it possible to add these new registers to the end (instead of the middle) of the register.table. The question then becomes one of should they be included by default. For the answer to that, ask Andreas Schwab [To:ed] who is the linux m68k maintainer. > 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. The ability to disable multi-arch is about to be deleted from current sources. Yes you'll have a problem. > 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 :) The current m68k sources are very up-to-date so hopefully the only problems you encounter are restricted to bdm. Andrew