This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Need Help for bringing m68k-based bdm target-patches form gdb-5.2.1 to gdb-5.3
- From: Josef Wolf <jw at raven dot inka dot de>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 6 Aug 2003 22:54:31 +0200
- 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> <jed6fisl1z.fsf@sykes.suse.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 --