On Tue, 2018-03-20 at 18:02 -0300, Pedro Franco de Carvalho wrote: > I noticed that __set_breakpoint in process.c calls set_dabr if > CPU_FTR_DAWR is not set. One case which could cause this to happen is if > perf events are not configured (and CONFIG_HW_BREAKPOINT is not set), > and someone calls ptrace with SET_DEBUGREG and data with a non-zero > address and 0 in the RDWR bits. In this case set_bp will be false, > thread.hw_brk will be set, and __switch_to will call __set_breakpoint, > which will call set_dabr. I'm not sure what happens if mtspr with DARN > is called on a P8. This last sentence should read "I'm not sure what happens if mtspr with DABR is called on a P9.", right? If so, then it should be a nop, but we should fix it to make it clearer in the code. > > Yeah, currently you'll get PPC_DEBUG_FEATURE_DATA_BP_RANGE and no > > PPC_DEBUG_FEATURE_DATA_BP_DAWR. > > > > If I set .features = 0 when !breakpoint_enabled() (as well as setting > > num_data_bps = 0 above), GDB seems to not like it when I run the program on > > P9: > > > > (gdb) r > > Starting program: /bin/true > > Warning: > > Could not insert hardware watchpoint 1. > > Could not insert hardware breakpoints: > > You may have requested too many hardware breakpoints/watchpoints. > > (gdb) > > > > So I think I'll leave this bits as I had in version 1 of the patch. > > This would make existing GDB releases work nicely, but it should > probably be fixed in GDB. > > When .features is 0, GDB ignores the rest of the info returned by > GETHWDBGINFO and assumes there will be at least one watchpoint register, > which leads to the behavior you described, and doesn't seem correct > (on the GDB side). Yeah, agreed Mikey -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
