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 at 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