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

[Josef Wolf <jw@raven.inka.de>]

On Wed, Aug 06, 2003 at 08:22:32PM +0200, Andreas Schwab wrote:

Thanks for your reply, Andreas!

> Josef Wolf <jw@raven.inka.de> 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 --