Hardware Breakpoint (or watchpoint) usage in Linux Kernel

Prasad Krishnan
IBM Linux Technology Centre
prasad@linux.vnet.ibm.com

Abstract breakpoint exception. We shall examine the details of

such an operation in the subsequent sections.
The Hardware Breakpoint (also known as watchpoint or
Possibly, the biggest convenience of using the hardware
debug) registers, hitherto was a frugally used resource
debug registers is that it causes no alteration in the nor-
in the Linux Kernel (ptrace and in-kernel debuggers
mal execution of the kernel or user-space when unused,
being the users), with little co-operation between the
and has no run-time impact. The most notable limitation
users. The role of these debug registers is best exem-
of this facility is the fewer number of debug registers on
plified in a) Nailing down the cause of memory cor-
most processors.
ruption, which be tricky considering that the symptoms
manifest long after the actual problem has occurred
and have serious consequences—the worst being a sys- 2 Hardware Breakpoint basics
tem/application crash. b) Gain better knowledge of data
access patterns to hint the compiler to generate better
A hardware breakpoint register’s primary (and only)
performing code. These debug registers can trigger ex-
task is to raise an exception when the monitored loca-
ceptions upon events (memory read/write/execute ac-
tion is accessed. However these registers are processor
cesses) performed on monitored address locations to
specific and their diversity manifests in several forms—
aid diagnosis of memory corruption and generation of
layout of the registers, modes of triggering the break-
profile data.
point exception (such as exception being triggered ei-
This paper will introduce the new generic interfaces and ther before or after the memory access operation) and
the underlying features of the abstraction layer for HW types of memory accesses that can be monitored by the
Breakpoint registers in Linux Kernel. The audience will processor (such as read, write or execute).
also be introduced to some of the design challenges
in developing interfaces over a highly diverse resource 2.1 Hardware breakpoint basics—An overview of
such as HW Breakpoint registers, along with a note on x86, PPC64 and S390
the future enhancements to the infrastructure.
Table 1 provides a quick overview of the breakpoint fea-
1 Introduction ture in various processors and compares them against
each other [1, 2].
Hardware Breakpoint interfaces introduced to the Linux
kernel provide an elegant mechanism to monitor mem- 3 Design Overview of Hardware Breakpoint
ory access or instruction executions. Such monitoring infrastructure
is very vital when debugging the system for data cor-
ruption. It can also be done to with a view to understand 3.1 Register allocation for kernel and user-space
memory access patterns and fine-tune the system for op- requests
timal performance.

The hardware breakpoint registers in several processors While debug registers would treat every breakpoint ad-
provide a mechanism to interrupt the programmed ex- dress in the same way, there is a fundamental dif-
ecution path to notify the user through of a hardware ference in the way kernel and user-space breakpoint

• 149 •
150 • Hardware Breakpoint (or watchpoint) usage in Linux Kernel

Features / Register Name Number of Data(D) / In- Breakpoint lengths (length

Processor Breakpoints structions(I) in Bytes)
x86/x86_64 Debug register (DR) 4 D/I 1, 2, 4 and 8 (x86_64 only)
PPC64 Data(Instruction) Address Break- 1 D / I (on 8
point register (DABR / IABR) selected
processors
only)
S390 Program Event Recording (PER) 1 D/I Varied length. Can monitor
range of addresses

Table 1: Processor Support Matrix

requests are effected. A user-space breakpoint be- In order to avoid fragmentation of debug registers upon
longing to one thread (and hence stored in struct an unregistration operation, all kernel-space breakpoints
thread_struct) will be active only on one proces- are “compacted” by shifting the debug register values by
sor at any given point of time. The kernel-space break- one-level although this is not possible for user-space re-
points, on the other hand should remain active on all quests as it would break the semantics of existing ptrace
processors of the system to remain effective since each implementation. This implies that even if a user-thread
of them can potentially run kernel code any time. This downgraded its usage of breakpoints from n to n - 1,
necessitates the propagation of kernel-space requests for the breakpoint infrastructure will continue to reserve n
(un)registration to all processors and is done through debug registers. A solution for this has been proposed
inter-processor interrupts (IPI). The per-thread user- in Section 8.1.
space breakpoint takes effect only just before the thread
is scheduled. This means that a system at run-time 3.2 Register Bookkeeping
can have as many breakpoint requests as the number
of threads running and the number of free (i.e., not in
Accounting of free and used debug registers is essential
use by kernel) breakpoint registers put together (number
for effective arbitration of requests, and allows multiple
of threads x number of available breakpoint registers)
users to exist concurrently. Debug register bookkeeping
since they can be active simultaneously without inter-
is done with the help of following variables and struc-
fering with each other.
tures.
On architectures (such as x86) containing more than one hbp_kernel[] – An array containing the list of
debug register per processor, the infrastructure arbitrates kernel-space breakpoint structures
between requests from multiple sources. To achieve
this, the implementation submitted to the Linux commu- this_hbp_kernel[] – A per-cpu copy of hbp_
nity (refer [3]) makes certain assumptions about the na- kernel maintained to mitigate the problem discussed
ture of requests for breakpoint registers from user-space in Section 7.2.
through ptrace syscall, and simplifies the design based
on them. hbp_kernel_pos – Variable denoting the next avail-
able debug register number past the last kernel break-
point. It is equal to HBP_NUM at the time of initialisa-
The register allocation is done on a first-come, first-
tion.
serve basis with the kernel-space requests being accom-
modated starting from the highest numbered debug reg- hbp_user_refcount[] – An array containing re-
ister growing towards the lowest; while user-space re- fcount of threads using a given debug register number.
quests are granted debug registers starting from the low- Thus a value x in any element of index n will indicate
est numbered register. Thus in case of x86, the infras- that there are x number of threads in user-space that cur-
tructure begins looking out for free registers beginning rently use n number of breakpoints, and so on.
from DR0 while for kernel-space requests it will begin
with DR3 thus reducing the scope for conflict of re- A system can accommodate new requests for break-
quests. points as long as the kernel-space breakpoints and those
 2009 Linux Symposium • 151

of any given thread (after accounting for the new re- int register_kernel_hw_breakpoint(struct hw_breakpoint *bp);
quest) in the system can be fit into the available debug int register_user_hw_breakpoint(struct task_struct *tsk,
struct hw_breakpoint *bp);
registers. In essence,

Debug registers >= Kernel Breakpoints

+ Max(Breakpoints in use by any given
thread) Figure 2: Hardware Breakpoint interfaces for registra-
tion of kernel and user space addresses
3.3 Optimisation through lazy debug register
switching struct hw_breakpoint {
void (*triggered)(struct hw_breakpoint *,
struct pt_regs *);
The removal of user-space breakpoint, happens not im- struct arch_hw_breakpoint info;
mediately when it is context switched-out of the proces- };
sor but only upon scheduling another thread that uses
the debug register in what we term as lazy debug regis-
ter switching. It is a minor optimisation that reduces Figure 3: Hardware Breakpoint structure
the overhead associated with storing/restoring break-
points associated with each thread during context switch
between various threads or processes. A thread that The generic breakpoint structure in the Linux kernel of
uses debug registers is flagged with TIF_DEBUG in the -tip git tree presently looks as seen in Figure 3.
flag member in struct thread_info, and such The triggered points to the call-back routine to be
threads are usually sparse in the system. If we must clear invoked from the exception context, while info con-
the user-space requests from the debug registers at the tains architecture-specific attributes such as breakpoint
time of context-switch (in __switch_to() itself), it length, type and address.
could be done either
A breakpoint register request through these interfaces
does not guarantee the allocation of a debug register and
• unconditionally on all debug registers not used by it is important to check its return value to determine suc-
the kernel or cess.
• only if the thread exiting the CPU had TIF_ Unavailability of free hardware breakpoint registers can
DEBUG flag set (which is false for a majority of be most common reason since hardware breakpoint reg-
the threads in the system). isters are a scarce resource on most processors. The re-
turn code in this case is -ENOSPC.
In both the cases, we would add a constant overhead The breakpoint request can be treated as invalid if one
to the context-switching code irrespective of any thread of the following is true.
using the debug register.
• Unsupported breakpoint length
4 The Hardware Breakpoint interface • Unaligned addresses

4.1 Hardware Breakpoint registration • Incorrect specification of monitored variable name

• Limitations of register allocation mechanism
The interfaces for hardware breakpoint registration for
kernel and user space addresses have signatures as noted
in Figure 2. 4.1.1 Unsupported breakpoint length

A call to register a breakpoint is accompanied by a While the breakpoint register can usually store one ad-
pointer to the breakpoint structure populated with cer- dress, the processor can be configured to monitor ac-
tain attributes of which some are architecture-specific. cesses for a range of addresses (using the stored address
152 • Hardware Breakpoint (or watchpoint) usage in Linux Kernel

User-space debuggers
(GDB)
USER-SPACE

ptrace() KERNEL-SPACE

register_user_hw_breakpoint() register_kernel_hw_breakpoint() In-kernel debuggers

(ksym_tracer)

arch_update_user_hw_breakpoint()

struct thread_struct {
...
...
Hardware breakpoint regs
struct hw_breakpoint *hbp[HBP_NUM]
... on_each_cpu(arch_update_kernel_hw_breakpoint)
...
}

IPI IPI IPI IPI

arch_update_kernel_hw_breakpoint() arch_update_kernel_hw_breakpoint() arch_update_kernel_hw_breakpoint() arch_update_kernel_hw_breakpoint()

HBKPT HBKPT HBKPT HBKPT

CPU 0 CPU 1 CPU 2
CPU (NR_CPUS -1)

arch_install_thread_hw_breakpoint() arch_install_thread_hw_breakpoint() arch_install_thread_hw_breakpoint() arch_install_thread_hw_breakpoint()

Context Switch - switch_to() Context Switch - switch_to() Context Switch - switch_to() Context Switch - switch_to()

schedule() schedule() schedule() schedule()

IPI - Inter Processor Interrupts

KEY USER-SPACE BREAKPOINTS KERNEL-SPACE BREAKPOINTS HBKPT - Hardware Breakpoint registers
NR_CPUS - Number of CPUs in the system

Figure 1: This figure illustrates the handling of requests from kernel and user-space by the breakpoint infrastructure

as a base). For instance, in certain x86_64 processor 4.1.2 Unaligned addresses

types, up to four different byte ranges of addresses can
be monitored depending upon the configuration. They
are byte length of 1, 2, 4, and 8. However on PPC64 ar-
chitectures, this is always a constant of 8 bytes. Thus a
given breakpoint request can be treated as valid or oth- Certain processors have register layouts that impose
erwise depending upon the host processor. The arch- alignment requirements on the breakpoint address. The
specific structure is designed to contain only those fields alignment requirements are in consonance with the
that are essential for proper initiation of a breakpoint re- breakpoint lengths supported on these processors. For
quest and all constant values are hard-wired inside the instance, in x86 processors the supported lengths as we
architecture code itself. know are 1, 2, 4, and 8 bytes which in turn dictates that
the addresses must be aligned to 0, 1, 3, and 7 bytes.
 2009 Linux Symposium • 153

4.1.3 Incorrect specification of monitored variable 4.2.1 Identification of stray exceptions

name
But before that, the handler execution code must be re-
The breakpoint interface is designed to accept kernel silient to recognise stray exceptions and ignore them.
symbol names directly as input for the location to be Such stray exceptions can be the result of one of causes
monitored by the breakpoint registers. Invalid values detailed below.
can be the result of incorrect symbol name. Since user-
Memory access operations on addresses that are outside
space symbols cannot be resolved to their addresses in
the monitored variable’s address range but within the
the kernel, their breakpoint requests would fail if accom-
breakpoint length. For instance, on PPC64 processors
panied by a symbol name. As a means to resolve a con-
the DABR always monitors for memory access opera-
flict, that may arise when incoherent kernel symbol and
tions (as specified in the last two bits of DABR) in the
address are mentioned, the address is considered valid
double word (8 bytes) starting from the address in the
and the supersedes the kernel symbol name.
register. However the user’s request would be limited to
only a given kernel variable (whose size is smaller than
a double-word). Hence any accesses in the memory re-
4.1.4 Limitations of register allocation mechanism gion adjacent to the monitored variable falling within
the breakpoint length’s scope causes the breakpoint ex-
ception to trigger.
The register allocation mechanism (as discussed in the
Design overview section above) may also result in fail- Lazy debug register switching causes stale data to be
ure of registration due to lack of debug registers despite present in debug registers (as discussed above in Sec-
availability of a different numbered physical register. tion 3.3) and can give rise to spurious exceptions. This
This is identified as a limitation of the present debug typically happens when a process accesses memory lo-
register allocation scheme, and virtualisation of debug cations that were monitored previously by a different
registers is planned as a solution for the same. process but are not reset due to lazy switching.

At the end of a successful registration request the user

can assume that the request for breakpoints are effected 4.2.2 Identification of breakpoint structure for in-
by storing kernel-space request on all CPUs and user- vocation of callback function
space requests only when the process is scheduled.
The user-space breakpoint requests are thread-specific
and so, stored in the struct thread_struct,
4.2 Hardware Breakpoint handler execution while kernel-space breakpoints being universal are
stored in global kernel data structures, namely hbp_
kernel as noted above in Section 3.2.
Almost all of the hardware breakpoint exception han-
dling code is in architecture specific code. This is due On x86 processors, which provide four debug registers it
to the fact that each architecture handles the breakpoint is more challenging to identify the corresponding break-
exception in its handler code differently. point structure, when compared to architectures that al-
low only one breakpoint at any point in time. Upon
However a few operations are common to the han- encountering a breakpoint exception, the bit settings in
dlers designed for x86 and PPC64. The primary ob- the status register for debugging DR6 is looked upon.
jective of the exception handler is to trigger the func- Based on the bits that are set, the appropriate breakpoint
tion registered as a callback during breakpoint regis- address register (DR0-DR3) is understood to have been
tration, which requires access to the correct instance the cause for the exception. Depending upon whether
of struct hw_breakpoint that was provided to the register was used by the kernel or user-space the
the breakpoint interface during registration. The correct breakpoint structure is retrieved from either the kernel’s
breakpoint structure has to be deciphered from a set of global data structure or the process’ instance of the per-
user-space and kernel-space breakpoint requests. thread structure respectively.
154 • Hardware Breakpoint (or watchpoint) usage in Linux Kernel

void unregister_kernel_hw_breakpoint(struct hw_breakpoint *); Sample output from ksym tracer

void unregister_user_hw_breakpoint(struct hw_breakpoint *,
# tracer: ksym_tracer
struct task_struct *); #
# TASK-PID CPU# Symbol Type Function
# | | | | |
bash 30897 3 pid_max RW .do_proc_dointvec_minmax_conv+0x78/0x10c
bash 30897 3 pid_max RW .do_proc_dointvec_minmax_conv+0xa0/0x10c

Figure 4: Hardware Breakpoint interfaces for unregis- bash

bash
30897 3 pid_max
30897 1 pid_max
RW .alloc_pid+0x8c/0x4a4
RW .alloc_pid+0x8c/0x4a4
tration of kernel and user space addresses

Figure 5: Sample output from ksym tracer collected

Using such architecture-specific methods to identify the
when tracing pid_max kernel variable for read and write
appropriate breakpoint structure, the user-defined call-
operations
back function is invoked.

This will be followed by post processing, which may

zero), it indicates the availability of one new free debug
include single-stepping of the causative instruction in
register since the last user of that debug register has re-
architectures where the breakpoint exception is taken
leased the resource.
when the impending instruction will cause the memory
operation monitored by the debug register.
Kernel-space breakpoints are loaded onto all debug reg-
Since the breakpoint handler is invoked through a noti- isters to the obvious fact that the kernel-code may be
fier call chain, the return code is used to decide if the executed on any and all processors at any given point
remaining handlers have to be invoked further. Detec- of time unlike the thread-specific breakpoints which run
tion of multiple causes for the exception will then be only on one processor at any given instant.
required to choose the appropriate return code and will
form part of the post processing code. Thus a removal request for kernel-space breakpoints
should be propagated to all processors (in the same fash-
ion as a registration request) through inter-processor in-
4.3 Hardware Breakpoint unregistration
terrupts. The process of unregistration is complete only
when the callbacks through the IPI in each of the CPU
Hardware breakpoint unregistration is done by invoking returns.
the appropriate kernel or user interface with a pointer to
the instance of breakpoint structure. An invocation to
the interface always results in successful removal of the
5 Beyond debugging of memory corruption—
breakpoint and hence doesn’t return any value to indi-
Ftrace, memory access tracing and data pro-
cate success or failure. The interfaces are as shown in
filing
4.

The ksym tracer is a plugin to the ftrace framework that

4.3.1 Need for per-cpu kernel breakpoint struc- allows a user to quickly trace a kernel variable for cer-
tures tain memory access operations and collect information
about the initiator of the access.
It is much safer and easier to remove user-space break-
points, compared to kernel-space requests (refer to 7 It provides an easy-to-use interface to the user to accept
section for a related issue). It requires updating of the kernel variable and a set of memory operations for
the appropriate bookkeeping counters and per-thread which the variable will be monitored. While, it is cur-
data structures containing breakpoint information (apart rently restricted to trace only in-kernel global variables,
from clearing the physical debug registers). While pro- the ksym_tracer’s parser can be extended to accept mod-
cessing user-space unregistration requests, if the break- ule variables and kernel-space addresses as input.
point removal causes the any member of hbp_user_
refcount[] to turn into zero (i.e., result in a state These traces can help in profiling memory access oper-
where there are no threads using the debug register cor- ations over data locations such as read-mostly or write-
responding to the array index of the member that turned mostly.
 2009 Linux Symposium • 155

Operation / Machine register_kernel unregister_kernel Operation / Machine Breakpoint handler

System A System B System A System B System A System B
Trial 1 5066 5770 244 24 Trial 1 2230 4677
Trial 2 5319 6279 204 21
Trial 2 1980 4255
Trial 3 5309 6193 228 20
Trial 4 6068 6092 206 18 Trial 3 1805 4224
Trial 4 1644 4035

Table 2: Time taken for (un)register_kernel operation in Table 3: Time taken for breakpoint handler with a
micro-seconds dummy callback function (in nano-seconds)

6 Overhead measurements of triggering

• provide a well-defined breakpoint execution han-
breakpoints dler behaviour despite the nuances in such
as trigger-before-execute and trigger-after-execute
Readings of the following measurements have been tab-
(which are dependant on the type of breakpoint and
ulated.
the host processor)

• Table 2 – Contains overhead measurements for reg- • balance between the the need for a uniform be-
ister and unregister requests on two systems. haviour and exploitation of unique processor fea-
tures
• Table 3 – Average time taken for the breakpoint
handler execution with a dummy trigger in four dif-
ferent trials on two systems. The implementation of such goals gave rise to chal-
lenges, some of which are discussed here.
The trials were conducted on two machines, System A
and B whose specifications are as below. 7.1 Ptrace integration
System A – 24 CPU x86_64 machine Intel(R) Xeon(R)
MP 4000 MHz The user-space has been the most common user of hard-
ware breakpoints through the ptrace system call. Ptrace
System B – 2 CPU i386 Intel(R) Pentium(R) 4 CPU interface’s ability to read or write from/into any phys-
3.20GHz ical register has been exploited to enable breakpoints
for user-space addresses. While it required little or no
These systems, chosen for tests are sufficiently diverse
knowledge about the host architecture’s debug registers,
in the number of CPUs in them to expose the overhead
it remained the responsibility of the application invoking
caused by of IPIs in the (un)register_kernel_
ptrace (such as GNU Debugger GDB) to be a knowl-
hw_breakpoint() operations. The readings were
edgeable user and activate/disable them through appro-
taken without any true workload on the systems.
priate control information.
While the overhead for unregister operations is greater
For instance, on x86 processors containing multiple de-
in System A (with many CPUs), interestingly this be-
bug registers and dedicated control and status registers
haviour does not manifest during the register operations
(unlike in PPC64 where the control and debug address
(Refer to Table 2).
registers are composite), operations such as read and
write become non-trivial—i.e., every request for a new
7 Challenges breakpoint must require one write operation on the de-
bug address register (DR0 - DR3) and one for the control
Among the the goals set during the design of the hard- register.
ware breakpoint infrastructure, a few to mention are:
Since ptrace is exposed to the user-space as a system
• provide a generic interface that abstracts out call it is important to preserve its error return behaviour.
the arch-specific variations in breakpoint facility Achieving this becomes complicated because of the fact
and allowing the end-user to harness this facility that ptrace and its user in the user-space assumes exclu-
through a consistent interface sive availability of the debug registers and are ignorant
156 • Hardware Breakpoint (or watchpoint) usage in Linux Kernel

of any kernel space users. Hence, the number of avail- handle exceptions through its own copy of the break-
able registers may be lesser than the ptrace user’s as- point data until removed. Although this generates mul-
sumption and may result in failure of request when not tiple copies of the same global data, it is much preferred
expected. over the alternatives such as global disabling of break-
points (through IPIs) before every unregister operation,
On architectures like x86 where the status of multiple due to the overhead associated with processing the IPIs
breakpoint requests can be modified through one ptrace (Refer Table 2 for data containing turnaround time for
call (using a write operation on debug control register register/unregister operations).
DR7), care is taken to avoid a partially fulfilled request
to prevent the debug registers from gaining a set of val-
ues that is different from the ptrace’s requested values 8 Future enhancements
and its past state. Consider a case where, among the
four debug registers, one was active and the remaining Enhanced abstraction of the interface to include defini-
three were disabled in the initial state. If the new re- tions of attributes that are common to several architec-
quest through ptrace was to de-activate the single active tures (such as read/write breakpoint types), widening the
breakpoint and enable the rest of them, then we do not support for more processors, improvements to the ca-
effect the breakpoint unregistration first but begin with pabilities, interface and output of ksym_tracer; cre-
the registration requests and this is done for a reason. ation of more end-users to support the breakpoint infras-
tructure such as “perfcounters” and SystemTap in inno-
Supposing that one of the breakpoint register operation vative ways are just a few enhancements contemplated
fails (due to one of the reasons noted above in Section at the moment for this feature.
4.1) and if it was preceded by the unregister operation
the result of the ptrace call is still considered a failure. Virtualised debug registers was a feature in one of the
The state of the debug registers must now be restored to versions of the patchset submitted to the Linux commu-
its previous one which implies that the breakpoint un- nity but was eventually dropped in favour of a simplified
registration operation must be reversed. Under certain approach to register allocation. The details of the feature
conditions this may not be possible leaving the debug and benefits are detailed below.
registers with an altogether new set of values.
8.1 Virtualisation of Debug registers
Thus all breakpoint disable requests in ptrace for x86 is
processed only after successful registration requests if In processors having multiple registers such as x86, re-
any. This prevents a window of opportunity for debug quests for breakpoint from ptrace are targeted for spe-
register grabbing by other requests thereafter leading to cific numbered debug register and is not a generic re-
a problem as described above. quest. While this mechanism works well in the absence
of any register allocation mechanism and when requests
7.2 Synchronised removal of kernel breakpoints from user-space have exclusive access to the debug reg-
isters, their inter-operability with other users is affected.
A kernel breakpoint unregistration request would re- The hardware breakpoint infrastructure discussed here,
quire updating of the global kernel breakpoint structure mitigates this problem to a certain extent by using the
and debug registers of all CPUs in the system (similar fact that requests from ptrace tend to grow upwards—
to the process of registration). However every processor i.e., starting from the lower numbered register to the
is susceptible to receive a breakpoint exception from the higher ones.
breakpoint that is pending removal although the related
global data structures may be cleared by then causing A true solution to this problem lies in creating a thin
indeterminate behaviour. layer that maps the physical debug registers to those re-
quested by ptrace and allow the any free debug regis-
This potential issue was circumvented by storing a per- ter to be allocated irrespective of the requested regis-
cpu copy of the global kernel breakpoint structures ter number. The ptrace request can continue to access
which would be updated in the context of IPI process- through the virtual debug register thus allo-
ing. It enables every processor to continue to receive and cated.
 2009 Linux Symposium • 157

8.2 Prioritisation of breakpoint requests of the patches by Alan Stern. The author gratefully ac-
knowledges their contribution.
Allow the user to specify the priority for breakpoint re-
Special thanks to Balbir Singh for initiating the author
quests to be handled. If a breakpoint request with a
into the creation of this paper and being a great source
higher priority arrives, the existing breakpoint yields the
of encouragement throughout.
debug register to accommodate the former. An accom-
paniment to this feature would be the callback routines The author wishes to thank Naren A Devaiah and the
that are invoked whenever a breakpoint request is pre- IBM management who generously provided an oppor-
empted or regains the debug registers on the processor. tunity to work on this feature and paper, without which
This is done at the time of every new registration to bal- its presentation at the Linux Symposium 2009 wouldn’t
ance the requests and accommodate requests based on have been possible.
their priorities.

This feature was a part of the original patchset but was

11 Legal Statements
subsequently removed based on community feedback
[4].
c International Business Machines Corporation 2007. Per-
mission to redistribute in accordance with Linux Symposium
9 Conclusions submission guidelines is granted; all other rights reserved.

This work represents the view of the author and does not nec-
The Hardware Breakpoint infrastructure and the as- essarily represent the view of IBM.
sociated consumers of the infrastructure such as
ksym_tracer makes available a hitherto scarcely IBM, IBM logo, ibm.com are trademarks of International
used hardware resource to good use in newer ways such Business Machines Corporation in the United States, other
as profiling and tracing apart from their vital roles in de- countries, or both.
bugging. The overhead in taking a breakpoint, as our
Linux is a registered trademark of Linus Torvalds in the
results in Section 6 show are tolerable even in produc-
United States, other countries, or both.
tion environments and if any would be the result of the
user-defined callback function. It is hoped that when Other company, product, and service names may be trade-
the patches head into the mainline kernel, a wider user- marks or service marks of others.
feedback and testing will help evolve the infrastructure
into a more powerful and robust one than the proposed. References in this publication to IBM products or services
do not imply that IBM intends to make them available in all
countries in which IBM operates.
10 Acknowledgements
INTERNATIONAL BUSINESS MACHINES CORPORA-
TION PROVIDES THIS PUBLICATION “AS IS” WITH-
The author wishes to thank his team at Linux Technol-
OUT WARRANTY OF ANY KIND, EITHER EX-
ogy Centre, IBM and the management for their encour-
PRESS OR IMPLIED, INCLUDING, BUT NOT LIM-
agement and support during the creation of the hardware
ITED TO, THE IMPLIED WARRANTIES OF NON-
breakpoint patchset and the paper.
INFRINGEMENT, MERCHANTABILITY OR FITNESS
The profound work done by Alan Stern, whose patch- FOR A PARTICULAR PURPOSE. Some states do not al-
set and ideas were the foundation for the present code in low disclaimer of express or implied warranties in certain
-tip tree, and an earlier patchset from Prasanna S Pan- transactions, therefore, this statement may not apply to you.
chamukhi need a mention of thanks from the author. This information could include technical inaccuracies or ty-
pographical errors. Changes are periodically made to the in-
The design of this feature is heavily influenced by sug- formation herein; these changes will be incorporated in new
gestions from Ingo Molnar and code was vetted by editions of the publication. IBM may make improvements
Ananth N Mavinakayanahalli, Frederic Weisbecker and and/or changes in the product(s) and/or the program(s) de-
Maneesh Soni; also benefiting from the in-depth review scribed in this publication at any time without notice.
158 • Hardware Breakpoint (or watchpoint) usage in Linux Kernel

References

[1] Intel Corporation. Intel 64 and IA-32 Architectures

Software Developer’s Manual, 2008.
www.intel.com/Assets/PDF/manual/
253669.pdf.

[2] International Business Machines Corporation.

TM
Power ISA Version 2.05, 2007.
http://www.power.org/resources/
reading/PowerISA_V2.05.pdf.

[3] K. Prasad. Hardware breakpoint interfaces, June

2009.
http://lkml.org/lkml/2009/6/1/282.

[4] K. Prasad. Introducing generic hardware

breakpoint handler interfaces, March 2009. http:
//lkml.org/lkml/2009/3/10/183.
Proceedings of the
Linux Symposium

July 13th–17th, 2009

Montreal, Quebec
Canada
 Conference Organizers
Andrew J. Hutton, Steamballoon, Inc., Linux Symposium,
Thin Lines Mountaineering

Programme Committee
Andrew J. Hutton, Steamballoon, Inc., Linux Symposium,
Thin Lines Mountaineering
James Bottomley, Novell
Bdale Garbee, HP
Dave Jones, Red Hat
Dirk Hohndel, Intel
Gerrit Huizenga, IBM
Alasdair Kergon, Red Hat
Matthew Wilson, rPath

Proceedings Committee
Robyn Bergeron
Chris Dukes, workfrog.com
Jonas Fonseca
John ‘Warthog9’ Hawley

With thanks to
John W. Lockhart, Red Hat

Authors retain copyright to all submitted papers, but have granted unlimited redistribution rights
to all as a condition of submission.