> Agh, Andy take a look at the sparc-stub.c file, on the Sparc all the
> registers are just thrown on the stack at trap time with down and
> dirty offsets plain and simple. There is no fundamental reason for
> you to rewrite pt_regs at all. In fact what I did was add a header
> called include/asm-sparc/kgdb.h and on the mips you could put your
> Mips KGDB specific register layout in there. Personally I only keep
> an extern or two for people to call breakpoint() etc.
Well, I'm not sure about how SPARCs handle exceptions, but I'm
quite convinced that this heavily differs from the MIPS way.
First, the MIPS does not have built-in exception vectors. I just
have 4 hardwired exception entry points for
1) TLB refill
2) XTLB refill
3) cache error
4) everything else
These vectors are not variable, they are fixed at 0x8000_0000,
0x8000_0080 and so on. That is, you cannot simply overwrite a
vector somewhere in memory to redirect exceptions.
Luckily, Linux/MIPS already has a vector system for all type 4)
exceptions, and the gdb stub uses these vectors. The processor
registers are already saved before jumping thru vectors, and into
a pt_regs struct. Furthermore, k0 and k1 are used to save registers,
and there's no other way to do it since MIPS do *not* have any
dedicated stack pointer nor any post-increment or pre-decrement or
even direct addressing modes. You need to use a register to save
another register. Well, that's RISC :-)
> So we have a couple of choices:
> a) change struct pt_regs and all associated macros and functions
> ugh don't do this...
> b) fake the values of zero (always 0 anyway) and k0,k1
> this neither. ;)
Why? Zero can never change. It is hardwired (not by software, by HARDWARE).
> c) change GDB
> this especially not ;)
> d) Give gdb stub the registers in the layout that it does expect them
> in and just leave it at that.
> No one except the gdb-stub handle_exception() will ever see this stuff,
> it's private to the debugger.
Sorry, that's not true, see above. The only other choice I have is
to overwrite the hardcoded exception handlers with jump instructions
to the GDB stub. Well, that would work but at this point it could
easily introduce new problems which I really don't like.
Anyway, I'll think about it. If I feel that the gdb stub is
reliable, I could try overwriting the basic exception handlers.
At this point, the handler work sufficient enough to be able
to check all other gdb features. If everything is fine I can try
to find another way.