From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26630 invoked by alias); 6 Aug 2003 20:55:30 -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 26597 invoked from network); 6 Aug 2003 20:55:25 -0000 Received: from unknown (HELO mail.inka.de) (193.197.184.2) by sources.redhat.com with SMTP; 6 Aug 2003 20:55:25 -0000 Received: from raven.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 19kVJc-000615-00; Wed, 06 Aug 2003 22:55:24 +0200 Received: from localhost (localhost [127.0.0.1]) by raven.inka.de (Postfix) with ESMTP id 98EAE1C2; Wed, 6 Aug 2003 22:54:31 +0200 (CEST) Received: by raven.inka.de (Postfix, from userid 500) id 463641C5; Wed, 6 Aug 2003 22:54:31 +0200 (CEST) Date: Wed, 06 Aug 2003 20:55:00 -0000 From: Josef Wolf To: Andreas Schwab 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 Message-ID: <20030806205431.GA3349@raven.inka.de> References: <20030731223514.GD20282@raven.inka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS snapshot-20020531 X-SW-Source: 2003-08/txt/msg00084.txt.bz2 On Wed, Aug 06, 2003 at 08:22:32PM +0200, Andreas Schwab wrote: Thanks for your reply, Andreas! > Josef Wolf writes: > > |> 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 */ > > There are 7 registers between fp0 and fpc, namely the other floating point > registers fp1 to fp7. You can't just renumber fp0 without renumbering the > others. This specific target (CPU32) doesn't have any floating point registers, so it shouldn't hurt in the case when BDM is used. I would like to bring the BDM-patches as close as possible to the generic m68k code. But I was somewhat confused, so I made this quick-n-dirty hack. > |> 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, > > But they are supervisor-only registers Ough? Does that mean that gdb should not be used to debug supervisor mode? Is this a political decision or are there technical reasons? > (btw, I have never heard of the pcc, atemp and far registers, they don't > exist on any of the variants of the m68k family I know of). FAR: Fault Address Register. Contains the address of the faulting bus cycle. PCC: Current Instruction Program Counter. This can differ from the user visible PC due to instruction pipelining. ATEMP: A TEMPorary register. This one can be used to distinguish between a double bus fault and a BGND instruction (which turns the CPU into BDM-Mode) These three registers are not user-visible. They are BDM-specific. So you are probably right that gdb doesn't need to know about them. But they can come handy when you are debugging your hardware. > |> so I wonder how E_FP0_REGNUM can be set to 18? > > Theses numbers are basically arbitrary, AFAIK. But there are places like for (regnum = FP0_REGNUM + 7; regnum >= FP0_REGNUM; regnum--) [ ... ] or for (regnum = FP_REGNUM - 1; regnum >= 0; regnum--) [ ... ] so they seemed not to be very arbitrary to me. BTW: I still don't have a clue what this MULTI_ARCH stuff is all about and how multi-arch targets are meant to be adopted. But it seems to me that the BDM patches should be brought towards this multi-arch structure on the long run. Does any overview and/or introduction into this topic exist? Something like a Add-A-New-Target-To-Gdb.HOWTO maybe? Thanks! -- Please visit and sign http://petition-eurolinux.org and http://www.ffii.org -- Josef Wolf -- jw@raven.inka.de --