I have a request for an additional feature to be includedin the recent hardware breakpoints work soon to be deliveredin kernel 2.6.33.

Frederic Weisbecker, Prasad Krishnan and I have shared an ongoingprivate discussion on this topic. Frederic recommended that we takethe discussion to a wider audience. Hence this email. I would liketo thank bothof those two engineers for their patience, quick response,and help in this process. They've been stellar.

I work for a company which would like to make heavy useof the new HW breakpoints perf_event work. Essentially,we need to be able to do the following:

1) When executed, a user-land application must be able to program 4pinned hardwarebreakpoint registers. I need 1 byte granularity (address lengthspecificity) and the abilityto set RWX event triggers.

2) All calls to clone() or fork() will propagate thedebug register settings from parent to child(ren).

3) When a breakpoint is triggered, the applicationthread currently running which triggered the breakpointimmediately stops execution and is sent a SIGTRAP.

4) The thread transitions from the PC that triggered the breakpoint tothe signal handler for SIGTRAP.

5) The signal handler does some work. (This "work" is outside thescope of my request, but you may have some insights. I need to beable to change the PC and nPC for the thread that triggered abreakpoint such that when itreturns from the signal handler it doesn't return to the instructionthat triggered the breakpoint but to the one after it. If I wereusing ptrace(8), I would just have the parentprocess use the ptrace(8) syscall to modify the PC andnPC of the child. I'm not using ptrace(8).)

6) The signal handler returns and the thread returns to normalexecution at the newPC and nPC.

From my discussions with Frederic and Prasad, I knowthat requirements (1) and (2), as described above,are already being met by the current work. I can usethe perf_event_attr structure and the perf_event syscallto program breakpoints for a thread in exactlythe way I've specified AND be able to have debugsettings inherited from parent to child in the case of afork() or clone().

However, there's nothing yet in place to allow asignal to be sent to the thread when a breakpointhas been hit. Put another way, there's nothing herewhich affects execution flow of the user-app when the CPUtraps due to a HW breakpoint.

Currently, the perf events infrastructure allows meto mmap() a block of memory and to poll() on it, waitingand watching for events to be described in that mmap'dbuffer. That will not be sufficient for what we needto do. We need to have the ability to specify thatexecution of the thread should be interrupted, just as itwould under ptrace(), and have a signal be delivered.Delivery of the signal must be received and processedby the application before the thread will be allowed toproceed to the nPC after the PC which caused theHW breakpoint event.

Is this possible? Can we architect this feature intothe perf_events infrastructure?

At first glance, it would seem that this is a fairlyeasy thing to do. Right now, these same HW breakpointstriggers under ptrace() merely call a previously registereduser handler which modifies the debug registers torecord the event and to propagate a signal to the childprocess being traced. We want to do something similarw/o using ptrace. Perhaps it is as simple as providing aperf_event_attr setting which indicates that SIGTRAP signalsshould be sent to the thread which triggered the breakpointexception.