overloading existing PTRACE_GET_DEBUGREG/PTRACE_SET_DEBUGREG commands

overloading existing PTRACE_GET_DEBUGREG/PTRACE_SET_DEBUGREG commands

[Kumar Gala]

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

Re: overloading existing PTRACE_GET_DEBUGREG/PTRACE_SET_DEBUGREG commands

[Roland McGrath]

For the short answer, no, I'd like not to extend PTRACE_SET_DEBUGREG in
the simple fashion.  The direction I want to move with this is away from
providing the hardware register formats directly as the user ABI.

What I mean is resurrecting, finishing, and porting the "hw_breakpoint"
work that Alan Stern <stern@rowland.harvard.edu> started, but which was
never finished or merged.  This is an in-kernel interface handling the
hardware details and multiplexing in-kernel and user uses, with a
higher-level API that is mostly machine-independent.  The idea is that
future user-level extensions for watchpoint-like features would be based
on that, not on exposing hardware features directly as such.

I think someone at IBM told me they were going to look at picking that
work up, but I'll have to remember who and track them down.

> Also, what functionality can GDB take advantage of today?  Does it  
> comprehend the idea of breakpoints or watchpoints that cover a range?

I'm not the expert on that, but probably the answer is "sort of".
The low-level feature on s390 is range-based, and it supports that.
The hook for machine support uses "addr+len", though on most machines
len has to be 8 or has to be {1,2,4,8} and addr has to be aligned to len.
I'm not sure that high-level watchpoints ever translate into big ranges
in practice.

Understanding the details of all the hardware features in the powerpc
variants would inform ironing out the hw_breakpoint interface details.


Thanks,
Roland