Register fudging (CRISv32)

Orjan Friberg orjan.friberg@axis.com
Mon Sep 6 12:00:00 GMT 2004


Daniel Jacobowitz wrote:
> 
> Precisely.  It sounds like the kernel can do a more accuarate job than
> gdbserver can easily.  For instance, if we single-step a task, and
> detach leaving it stopped, and attach another debugger - that debugger
> won't have the state to know whether the task was last stepped or
> trapped.

I sort of see what you're saying (though I'm not sure I understand your 
example: the register contents would be the same when attaching again, 
which is what the pseudo-PC is calculated from).  Anyways, I'm going to 
try and implement the creation of the pseudo-PC in the kernel - I'm not 
entirely happy with having it in the Gdbserver, and it also has it flaws 
(for example, sigaltstack.exp generating several FAILs if we receive the 
signal in a delay slot).

>>For example, in case of a PTRACE_CONT I set the single-step PC to 0 to 
>>disable single-stepping (similar to what the m68k does).
> 
> 
> Ah, I think I see.  I don't remember what your original question was
> though :-)

It was just one example of register fudging that seemed appropriate to 
do in the kernel.

-- 
Orjan Friberg
Axis Communications



More information about the Gdb mailing list