overloading existing PTRACE_GET_DEBUGREG/PTRACE_SET_DEBUGREG commands

[Kumar Gala <galak@kernel.crashing.org>]

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