linux-mips-fnet
[Top] [All Lists]

Re: kgdb and Linux/MIPS

To: linux-mips@fnet.fr
Subject: Re: kgdb and Linux/MIPS
From: Ralf Baechle <ralf@waldorf-gmbh.de>
Date: Fri, 1 Sep 1995 21:02:25 +0200 (MET DST)
In-reply-to: <199508301836.UAA10759@newton.waldorf-gmbh.de> from "Andreas Busse" at Aug 30, 95 08:36:53 pm
Hi all,

> I have some (limited) success with kgdb. At least, both machines
> connect, the GDB on my Intel box happily talks to the Mips and
> gets response.
> So far, so good. The bad thing is that the usual exception handlers
> of Linux/MIPS do not save all registers, nor in the order GDB 
> expects them. That leads of course to some mysterious behaviour :-)
> 
> Question is: Would it hurt to change the struct pt_regs plus the
> the macros SAVE_ALL, RESTORE_ALL and everything related so that
> all required registers are saved, or shall I write my own 
> SAVE_ALL_GDB and RESTORE_ALL_GDB macros and a new struct containing
> the regs ?
> 
> GDB expects following regs in this order:
> 
> $0 ... $31    ($0 isn't worth to store, I know :-))
> CP0_STATUS,
> CP0_EPC,
> LO, HI,
> BAD_VADDR
> 
> Most of them are availabe thru pt_regs. Only zero ($0),
> k0 ($26) and k1 ($27) are missing. 
> 
> So we have a couple of choices:
> a) change struct pt_regs and all associated macros and functions
> b) fake the values of zero (always 0 anyway) and k0,k1
> c) change GDB
> 
> I would favourize a), but b) would also work. Changing GDB
> isn't a good idea, I believe.

I intend to change struct pt_regs & SAVE_ALL/RESTORE_ALL anyway.
They really save to much on the stack.  It's probably the best
when the remote debugging support in the kernel that you have to
hack anyway fakes the stack order for GDB or so.  Will have to dive
into the internal of GDB ...

  Ralf

<Prev in Thread] Current Thread [Next in Thread>