AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-26 00:25:33 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
ba72b5a499
linux_dsm_epyc7002/arch/arm/include/asm/hw_breakpoint.h

140 lines
3.5 KiB
C
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 21:07:57 +07:00
/* SPDX-License-Identifier: GPL-2.0 */
ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework The hw-breakpoint framework in the kernel requires architecture-specific support in order to install, remove, validate and manage hardware breakpoints. This patch adds initial support for this framework to the ARM architecture, but restricts the number of watchpoints to a single resource to get around the fact that the Data Fault Address Register is unknown when a watchpoint debug exception is taken. On cores with v7 debug, the Kernel can handle breakpoint and watchpoint exceptions occuring from userspace. Older cores require clients to handle the exception themselves by registering an appropriate overflow handler or, in the case of ptrace, handling the raised SIGTRAP. The memory-mapped extended debug interface is unsupported due to its unreliability in real implementations. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:41:08 +07:00
#ifndef _ARM_HW_BREAKPOINT_H
#define _ARM_HW_BREAKPOINT_H
#ifdef __KERNEL__
ARM: 6357/1: hw-breakpoint: add new ptrace requests for hw-breakpoint interaction For debuggers to take advantage of the hw-breakpoint framework in the kernel, it is necessary to expose the API calls via a ptrace interface. This patch exposes the hardware breakpoints framework as a collection of virtual registers, accesible using PTRACE_SETHBPREGS and PTRACE_GETHBPREGS requests. The breakpoints are stored in the debug_info struct of the running thread. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:42:55 +07:00
struct task_struct;
#ifdef CONFIG_HAVE_HW_BREAKPOINT
ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework The hw-breakpoint framework in the kernel requires architecture-specific support in order to install, remove, validate and manage hardware breakpoints. This patch adds initial support for this framework to the ARM architecture, but restricts the number of watchpoints to a single resource to get around the fact that the Data Fault Address Register is unknown when a watchpoint debug exception is taken. On cores with v7 debug, the Kernel can handle breakpoint and watchpoint exceptions occuring from userspace. Older cores require clients to handle the exception themselves by registering an appropriate overflow handler or, in the case of ptrace, handling the raised SIGTRAP. The memory-mapped extended debug interface is unsupported due to its unreliability in real implementations. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:41:08 +07:00
struct arch_hw_breakpoint_ctrl {
u32 __reserved : 9,
mismatch : 1,
: 9,
len : 8,
type : 2,
privilege : 2,
enabled : 1;
};
struct arch_hw_breakpoint {
u32 address;
u32 trigger;
ARM: hw_breakpoint: unify single-stepping code for watchpoints and breakpoints The single-stepping code is currently different depending on whether we are stepping over a breakpoint or a watchpoint. There is no good reason for this, so let's sort it out. This patch adds functions for enabling/disabling single-step for a particular hw_breakpoint and integrates this with the exception handling code. Signed-off-by: Will Deacon <will.deacon@arm.com>
2010-12-01 21:12:13 +07:00
struct arch_hw_breakpoint_ctrl step_ctrl;
struct arch_hw_breakpoint_ctrl ctrl;
ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework The hw-breakpoint framework in the kernel requires architecture-specific support in order to install, remove, validate and manage hardware breakpoints. This patch adds initial support for this framework to the ARM architecture, but restricts the number of watchpoints to a single resource to get around the fact that the Data Fault Address Register is unknown when a watchpoint debug exception is taken. On cores with v7 debug, the Kernel can handle breakpoint and watchpoint exceptions occuring from userspace. Older cores require clients to handle the exception themselves by registering an appropriate overflow handler or, in the case of ptrace, handling the raised SIGTRAP. The memory-mapped extended debug interface is unsupported due to its unreliability in real implementations. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:41:08 +07:00
};
static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
{
return (ctrl.mismatch << 22) | (ctrl.len << 5) | (ctrl.type << 3) |
(ctrl.privilege << 1) | ctrl.enabled;
}
static inline void decode_ctrl_reg(u32 reg,
struct arch_hw_breakpoint_ctrl *ctrl)
{
ctrl->enabled = reg & 0x1;
reg >>= 1;
ctrl->privilege = reg & 0x3;
reg >>= 2;
ctrl->type = reg & 0x3;
reg >>= 2;
ctrl->len = reg & 0xff;
reg >>= 17;
ctrl->mismatch = reg & 0x1;
}
/* Debug architecture numbers. */
#define ARM_DEBUG_ARCH_RESERVED 0 /* In case of ptrace ABI updates. */
#define ARM_DEBUG_ARCH_V6 1
#define ARM_DEBUG_ARCH_V6_1 2
#define ARM_DEBUG_ARCH_V7_ECP14 3
#define ARM_DEBUG_ARCH_V7_MM 4
ARM: hw_breakpoint: add initial Cortex-A15 (debug v7.1) support This patch adds initial support for Cortex-A15 (debug architecture v7.1) to the hw_breakpoint ARM backend. Signed-off-by: Will Deacon <will.deacon@arm.com>
2011-07-23 00:27:37 +07:00
#define ARM_DEBUG_ARCH_V7_1 5
ARM: 7948/1: hw_breakpoint: Add ARMv8 support Add the trivial support necessary to get hardware breakpoints working for GDB on ARMv8 simulators running in AArch32 mode. Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Christopher Covington <cov@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-01-30 04:01:31 +07:00
#define ARM_DEBUG_ARCH_V8 6
ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework The hw-breakpoint framework in the kernel requires architecture-specific support in order to install, remove, validate and manage hardware breakpoints. This patch adds initial support for this framework to the ARM architecture, but restricts the number of watchpoints to a single resource to get around the fact that the Data Fault Address Register is unknown when a watchpoint debug exception is taken. On cores with v7 debug, the Kernel can handle breakpoint and watchpoint exceptions occuring from userspace. Older cores require clients to handle the exception themselves by registering an appropriate overflow handler or, in the case of ptrace, handling the raised SIGTRAP. The memory-mapped extended debug interface is unsupported due to its unreliability in real implementations. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:41:08 +07:00
/* Breakpoint */
#define ARM_BREAKPOINT_EXECUTE 0
/* Watchpoints */
#define ARM_BREAKPOINT_LOAD 1
#define ARM_BREAKPOINT_STORE 2
ARM: hw_breakpoint: add support for multiple watchpoints ARM debug architecture 7.1 mandates that the DFAR is updated on a watchpoint debug exception to contain the faulting virtual address of the memory access. This allows us to determine which watchpoints have fired and therefore report useful information to userspace. This patch adds support for using the DFAR in the watchpoint handler, which allows us to support multiple watchpoints on CPUs implementing the new debug architecture. Signed-off-by: Will Deacon <will.deacon@arm.com>
2011-08-02 22:16:57 +07:00
#define ARM_FSR_ACCESS_MASK (1 << 11)
ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework The hw-breakpoint framework in the kernel requires architecture-specific support in order to install, remove, validate and manage hardware breakpoints. This patch adds initial support for this framework to the ARM architecture, but restricts the number of watchpoints to a single resource to get around the fact that the Data Fault Address Register is unknown when a watchpoint debug exception is taken. On cores with v7 debug, the Kernel can handle breakpoint and watchpoint exceptions occuring from userspace. Older cores require clients to handle the exception themselves by registering an appropriate overflow handler or, in the case of ptrace, handling the raised SIGTRAP. The memory-mapped extended debug interface is unsupported due to its unreliability in real implementations. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:41:08 +07:00
/* Privilege Levels */
#define ARM_BREAKPOINT_PRIV 1
#define ARM_BREAKPOINT_USER 2
/* Lengths */
#define ARM_BREAKPOINT_LEN_1 0x1
#define ARM_BREAKPOINT_LEN_2 0x3
#define ARM_BREAKPOINT_LEN_4 0xf
#define ARM_BREAKPOINT_LEN_8 0xff
/* Limits */
#define ARM_MAX_BRP 16
#define ARM_MAX_WRP 16
#define ARM_MAX_HBP_SLOTS (ARM_MAX_BRP + ARM_MAX_WRP)
/* DSCR method of entry bits. */
#define ARM_DSCR_MOE(x) ((x >> 2) & 0xf)
#define ARM_ENTRY_BREAKPOINT 0x1
#define ARM_ENTRY_ASYNC_WATCHPOINT 0x2
#define ARM_ENTRY_SYNC_WATCHPOINT 0xa
/* DSCR monitor/halting bits. */
#define ARM_DSCR_HDBGEN (1 << 14)
#define ARM_DSCR_MDBGEN (1 << 15)
ARM: hw_breakpoint: Check function for OS Save and Restore mechanism v7 debug introduced OS Save and Restore mechanism. On a v7 debug SinglePower system, i.e a system without a separate core and debug power domain, which does not support external debug over powerdown, it is implementation defined whether OS Save and Restore is implemented. v7.1 debug requires OS Save and Restore mechanism. v6 debug and v6.1 debug do not implement it. A new global variable bool has_ossr is introduced and is determined in arch_hw_breakpoint_init() like debug_arch or the number of BRPs/WRPs. The logic how to check if OS Save and Restore is supported has changed with this patch. In reset_ctrl_regs() a mask consisting of OSLM[1] (OSLSR.3) and OSLM[0] (OSLSR.0) was used to check if the system supports OS Save and Restore. In the new function core_has_os_save_restore() only OSLM[0] is used. It is not necessary to check OSLM[1] too since it is v7.1 debug specific and v7.1 debug requires OS Save and Restore and thus OS Lock. Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2012-10-15 03:08:14 +07:00
/* OSLSR os lock model bits */
#define ARM_OSLSR_OSLM0 (1 << 0)
ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework The hw-breakpoint framework in the kernel requires architecture-specific support in order to install, remove, validate and manage hardware breakpoints. This patch adds initial support for this framework to the ARM architecture, but restricts the number of watchpoints to a single resource to get around the fact that the Data Fault Address Register is unknown when a watchpoint debug exception is taken. On cores with v7 debug, the Kernel can handle breakpoint and watchpoint exceptions occuring from userspace. Older cores require clients to handle the exception themselves by registering an appropriate overflow handler or, in the case of ptrace, handling the raised SIGTRAP. The memory-mapped extended debug interface is unsupported due to its unreliability in real implementations. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:41:08 +07:00
/* opcode2 numbers for the co-processor instructions. */
#define ARM_OP2_BVR 4
#define ARM_OP2_BCR 5
#define ARM_OP2_WVR 6
#define ARM_OP2_WCR 7
/* Base register numbers for the debug registers. */
#define ARM_BASE_BVR 64
#define ARM_BASE_BCR 80
#define ARM_BASE_WVR 96
#define ARM_BASE_WCR 112
/* Accessor macros for the debug registers. */
ARM: hw_breakpoint: use CRn as argument for debug reg accessor macros The coprocessor register CRn for accesses to the debug register can be a different one than C0. Take this into account for the ARM_DBG_READ and the ARM_DBG_WRITE macro. The inline assembler calls which used a coprocessor register CRn other than C0 are replaced by the ARM_DBG_READ or ARM_DBG_WRITE macro. Tested-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2012-09-26 23:28:47 +07:00
#define ARM_DBG_READ(N, M, OP2, VAL) do {\
asm volatile("mrc p14, 0, %0, " #N "," #M ", " #OP2 : "=r" (VAL));\
ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework The hw-breakpoint framework in the kernel requires architecture-specific support in order to install, remove, validate and manage hardware breakpoints. This patch adds initial support for this framework to the ARM architecture, but restricts the number of watchpoints to a single resource to get around the fact that the Data Fault Address Register is unknown when a watchpoint debug exception is taken. On cores with v7 debug, the Kernel can handle breakpoint and watchpoint exceptions occuring from userspace. Older cores require clients to handle the exception themselves by registering an appropriate overflow handler or, in the case of ptrace, handling the raised SIGTRAP. The memory-mapped extended debug interface is unsupported due to its unreliability in real implementations. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:41:08 +07:00
} while (0)
ARM: hw_breakpoint: use CRn as argument for debug reg accessor macros The coprocessor register CRn for accesses to the debug register can be a different one than C0. Take this into account for the ARM_DBG_READ and the ARM_DBG_WRITE macro. The inline assembler calls which used a coprocessor register CRn other than C0 are replaced by the ARM_DBG_READ or ARM_DBG_WRITE macro. Tested-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2012-09-26 23:28:47 +07:00
#define ARM_DBG_WRITE(N, M, OP2, VAL) do {\
asm volatile("mcr p14, 0, %0, " #N "," #M ", " #OP2 : : "r" (VAL));\
ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework The hw-breakpoint framework in the kernel requires architecture-specific support in order to install, remove, validate and manage hardware breakpoints. This patch adds initial support for this framework to the ARM architecture, but restricts the number of watchpoints to a single resource to get around the fact that the Data Fault Address Register is unknown when a watchpoint debug exception is taken. On cores with v7 debug, the Kernel can handle breakpoint and watchpoint exceptions occuring from userspace. Older cores require clients to handle the exception themselves by registering an appropriate overflow handler or, in the case of ptrace, handling the raised SIGTRAP. The memory-mapped extended debug interface is unsupported due to its unreliability in real implementations. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:41:08 +07:00
} while (0)
struct notifier_block;
struct perf_event;
struct pmu;
extern int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
int *gen_len, int *gen_type);
extern int arch_check_bp_in_kernelspace(struct perf_event *bp);
extern int arch_validate_hwbkpt_settings(struct perf_event *bp);
extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
unsigned long val, void *data);
ARM: 6357/1: hw-breakpoint: add new ptrace requests for hw-breakpoint interaction For debuggers to take advantage of the hw-breakpoint framework in the kernel, it is necessary to expose the API calls via a ptrace interface. This patch exposes the hardware breakpoints framework as a collection of virtual registers, accesible using PTRACE_SETHBPREGS and PTRACE_GETHBPREGS requests. The breakpoints are stored in the debug_info struct of the running thread. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:42:55 +07:00
ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework The hw-breakpoint framework in the kernel requires architecture-specific support in order to install, remove, validate and manage hardware breakpoints. This patch adds initial support for this framework to the ARM architecture, but restricts the number of watchpoints to a single resource to get around the fact that the Data Fault Address Register is unknown when a watchpoint debug exception is taken. On cores with v7 debug, the Kernel can handle breakpoint and watchpoint exceptions occuring from userspace. Older cores require clients to handle the exception themselves by registering an appropriate overflow handler or, in the case of ptrace, handling the raised SIGTRAP. The memory-mapped extended debug interface is unsupported due to its unreliability in real implementations. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:41:08 +07:00
extern u8 arch_get_debug_arch(void);
extern u8 arch_get_max_wp_len(void);
ARM: 6357/1: hw-breakpoint: add new ptrace requests for hw-breakpoint interaction For debuggers to take advantage of the hw-breakpoint framework in the kernel, it is necessary to expose the API calls via a ptrace interface. This patch exposes the hardware breakpoints framework as a collection of virtual registers, accesible using PTRACE_SETHBPREGS and PTRACE_GETHBPREGS requests. The breakpoints are stored in the debug_info struct of the running thread. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:42:55 +07:00
extern void clear_ptrace_hw_breakpoint(struct task_struct *tsk);
ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework The hw-breakpoint framework in the kernel requires architecture-specific support in order to install, remove, validate and manage hardware breakpoints. This patch adds initial support for this framework to the ARM architecture, but restricts the number of watchpoints to a single resource to get around the fact that the Data Fault Address Register is unknown when a watchpoint debug exception is taken. On cores with v7 debug, the Kernel can handle breakpoint and watchpoint exceptions occuring from userspace. Older cores require clients to handle the exception themselves by registering an appropriate overflow handler or, in the case of ptrace, handling the raised SIGTRAP. The memory-mapped extended debug interface is unsupported due to its unreliability in real implementations. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:41:08 +07:00
int arch_install_hw_breakpoint(struct perf_event *bp);
void arch_uninstall_hw_breakpoint(struct perf_event *bp);
void hw_breakpoint_pmu_read(struct perf_event *bp);
int hw_breakpoint_slots(int type);
ARM: 6357/1: hw-breakpoint: add new ptrace requests for hw-breakpoint interaction For debuggers to take advantage of the hw-breakpoint framework in the kernel, it is necessary to expose the API calls via a ptrace interface. This patch exposes the hardware breakpoints framework as a collection of virtual registers, accesible using PTRACE_SETHBPREGS and PTRACE_GETHBPREGS requests. The breakpoints are stored in the debug_info struct of the running thread. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:42:55 +07:00
#else
static inline void clear_ptrace_hw_breakpoint(struct task_struct *tsk) {}
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework The hw-breakpoint framework in the kernel requires architecture-specific support in order to install, remove, validate and manage hardware breakpoints. This patch adds initial support for this framework to the ARM architecture, but restricts the number of watchpoints to a single resource to get around the fact that the Data Fault Address Register is unknown when a watchpoint debug exception is taken. On cores with v7 debug, the Kernel can handle breakpoint and watchpoint exceptions occuring from userspace. Older cores require clients to handle the exception themselves by registering an appropriate overflow handler or, in the case of ptrace, handling the raised SIGTRAP. The memory-mapped extended debug interface is unsupported due to its unreliability in real implementations. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: S. Karthikeyan <informkarthik@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-03 16:41:08 +07:00
#endif /* __KERNEL__ */
#endif /* _ARM_HW_BREAKPOINT_H */
Reference in New Issue Copy Permalink