On Friday 17 April 2009 12:22:37 Josh Boyer wrote: > On Fri, Apr 17, 2009 at 11:46 AM, John Linn <john.l...@xilinx.com> wrote: > > Josh, any thoughts on putting this into head_44x.S? > > The code in the fsl file looks like the right solution. I do have an > odd question though, in that it's hard for the > kernel to really know if something like a BDI is running. Namely, > that config option doesn't cover RiscWatch in an obvious manner.
Yeah, setting DBCR0 would interfere with all JTAG probes. The ifdef meands you can't support both a JTAG debugger and hardware breakpoints in the same binary? Now that's an annoying restriction. > I also wonder if it's possible to have a host system be setting those > registers in a guest KVM system so the guest could be debugged with > gdb... Hollis, any idea on that? You mean is KVM currently doing that, and would this patch conflict with that behavior? Right now KVM (on 440) context switches the necessary DB* registers for out- of-band debugging. That is, qemu sends a "set breakpoint in guest" ioctl to KVM, and then when switching from host to guest mode, KVM will save the old DB* values, put in some new ones, and swap them back again when re-entering the host. So I *think* the answer to your question is "yes, KVM messes with these registers to enable software breakpoints when debugging a guest with gdb." That code path isn't heavily tested, but the values put into DB* by other host code shouldn't matter. However, KVM doesn't support in-band breakpoints, i.e. it doesn't emulate the setting of those registers from within the guest. It's basically a no-op. So whether the kernel sets them or not, in-band debugging won't work with the current KVM code. -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev