[RFC] Debugging with a HW probe.

[Jimi Xenidis]

On Aug 8, 2006, at 9:22 PM, Milton Miller wrote:

> On Sun Aug  6 2006 09:42:16 AM CDT, Jimi Xenidis wrote:
>> On the XenPPC project we've been playing around with using GDB to
>> source debug Linux (and Xen) using a RiscWatch HW probe.
>
>> We have found it useful to teach xmon to make this call so we can  
>> then
>> debug the SW thru the probe. Is this useful to anyone else
>
> Since you only invoke the attention on command from the debugger, how
> is this better than just invoking the stop command from the probe?   
> Is it you
> are not dispatched out?  That you are not at a random point in the  
> input
> polling?

Thats exactly it!
If I get the probe to stop the CPU I could stop in the OS or in a  
user app.  Since we are working on Xen it could be Xen or any number  
of OSes or user apps on OSes.
When interrogating the machine state, the probe (almost) respects the  
modes of the CPU and MMU so memory accesses are translated (if xlate  
is on).  Since, probe "soft breakpoints" are ATTN instructions as  
well they get written into memory by the probe.

Having SW "call out" allows me to make sure that I'm in the address  
space I care about.
Since I only invoke it from xmon it assumes you have xmon support and  
to really be useful you need to SysReq to xmon.
I could be useful to make this part of SysReq, but I think we want to  
make sure that its use is entirely intentional.
You can also insert 'asm volatile(".long 0x200;nop");' in you own  
code or even add it to BUG()/panic() and skip the suffering the xmon/ 
SysReq trap.

BTW: I say "almost" because the probe does not respect the truncating  
of the upper bits when xlate is off and 0xC00... addresses are  
useless, we hacked the gdb stub to work around that.
BTW2: (I'm sure obvious to some), Since the probe writes ATTN  
instructions, I do not know what would happen if the probe wrote ATTN  
to an unmapped page, this is why debugging user space might be useless.
-JX