It looks like when Anton added the PTRACE_GET_DEBUGREG/
PTRACE_SET_DEBUGREG he envisioned future chips having more than one
IABR/DABR.
I'm wondering what the feeling is about using the commands for
handling some of the sub-arch variants we have:
e300 (603 style machine) - adds IABR2, DABR2, IBCR (control) and DBCR
(control). We can use IABR1/2 (and DABR1/2) either as unique
addresses or for various ranges (inclusive or exclusive)
Book-e class machines can have the following registers: DBCR[0-2],
IAC1-4, DAC1-2, DVC1-2, DBSR. IACs are roughly equivalent to IABRs,
DACs are roughly equivalent to DABRs. Booke has similar ability to
the e300 to do inclusive, exclusive ranges as well as some other
features.
My question is how to handle providing access to the debug resources
we have on these other machine types. Should we just use GET_DEBUGREG/
SET_DEBUGREG and specify what the buffers look like for these specific
machine types? Is it ok to overload the commands this way? How does
this play with utrace?
Also, what functionality can GDB take advantage of today? Does it
comprehend the idea of breakpoints or watchpoints that cover a range?
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
