[RFC] Debugging with a HW probe.
jimix at watson.ibm.com
Wed Aug 9 20:44:38 EST 2006
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
>> 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
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/
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.
More information about the Linuxppc-dev