Luis Machado writes: > This is a patch that has been sitting idle for quite some time. I > decided to move it further because it is something useful. It was > originally written by Michel Darneille, based off of 2.6.16. > > The original patch, though, was not compatible with the current DABR > logic. DABR's are used to implement hardware watchpoint support for > ppc64 processors (i.e. 970, Power5 etc). 4xx's have a different > debugging register layout and needs to be handled differently (they two > registers: DAC and DBCR0).
Yes, they are different, but they do essentially the same thing, so I think we should try and unify the handling of the two. Maybe you could rename set_dabr() to set_hw_watchpoint() or something and make it set DABR on 64-bit and "classic" 32-bit processors, and DAC on 4xx/Book E processors. Likewise, I don't think we need both a "dabr" field and a "dac" field in the thread_struct - one should do. Rename "dabr" to something else if you feel that the "dabr" name is too ppc64-specific. And I don't think we need both __debugger_dabr_match and __debugger_dac_match. > 5) This is something i'm worried about for future features. We currently > have a way to support only Hardware Watchpoints, but not Hardware > Breakpoints (on 64-bit processors that have a IABR register or 32-bit > processors carrying the IAC register). Looking at the code, we don't > differentiate a watchpoint from a breakpoint request. A ptrace call has > currently 3 arguments: REQUEST, ADDR and DATA. We use REQUEST and DATA > to set a hardware watchpoint. Maybe we could use the ADDR parameter to > set a hardware breakpoint? Or use it to tell the kernel whether we want > a hardware watchpoint or hardware breakpoint and then pass the address > of the instruction/data through the DATA parameter? What do you think? I would think there would be a different REQUEST value to mean "set a hardware breakpoint". Roland McGrath (cc'd) might be able to tell us what other architectures do. Paul. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
