Re: gdbserver-6.3 : Next command gets stuck then zooms.

["Nathan J. Williams" <nathanw at wasabisystems dot com>]

vexspam-gdbmail@usa.net writes:

> In the Virtex-4 (405-ish as you know) the MSR doesn't have a single step
> enable (SE bit) - it does have a debug interrupt enable (DE bit).
> 
> If you know - what is the expected flow of operations I should be seeing
> for the next command?

Roughly, what the kernel should do is to set the DE bit in the MSR and
also set the Instruction Complete (ICMP) bit in DBCR0, which gives you
a trap after each instruction. However, you have to be sure your trap
handler for the debug exception can handle (ignore and return from,
mostly) debug traps that happen at the first instruction of *other*
exception handlers, because the DE bit of the MSR isn't cleared when,
for example, you take a TLB miss exception.

So gdbserver calls ptrace(PTRACE_SSTEP), the kernel turns on ICMP and
sets DE in the process's MSR, returns to userland, takes a TLB miss on
the instruction for whatever reason, enters the TLB miss handler, and
then takes a debug exception for the completion of the first
instruction in the TLB miss handler. The debug exception handler needs
to notice this (perhaps by checking the value of CSRR0 against known
kernel code addresses or known exception handler code addresses),
clear DE in CSRR1 but leave it alone in SRR1, and return to the TLB
miss handler. The miss handler will then finish unmolested and return
to the program, which can *then* trigger the debug exception for
completing an instruction you were actually interested in.

Have fun!

        - Nathan