1*caab277bSThomas Gleixner /* SPDX-License-Identifier: GPL-2.0-only */
2bcf5763bSVijaya Kumar K /*
3bcf5763bSVijaya Kumar K * AArch64 KGDB support
4bcf5763bSVijaya Kumar K *
5bcf5763bSVijaya Kumar K * Based on arch/arm/include/kgdb.h
6bcf5763bSVijaya Kumar K *
7bcf5763bSVijaya Kumar K * Copyright (C) 2013 Cavium Inc.
8bcf5763bSVijaya Kumar K * Author: Vijaya Kumar K <vijaya.kumar@caviumnetworks.com>
9bcf5763bSVijaya Kumar K */
10bcf5763bSVijaya Kumar K
11bcf5763bSVijaya Kumar K #ifndef __ARM_KGDB_H
12bcf5763bSVijaya Kumar K #define __ARM_KGDB_H
13bcf5763bSVijaya Kumar K
14bcf5763bSVijaya Kumar K #include <linux/ptrace.h>
15bcf5763bSVijaya Kumar K #include <asm/debug-monitors.h>
16bcf5763bSVijaya Kumar K
17bcf5763bSVijaya Kumar K #ifndef __ASSEMBLY__
18bcf5763bSVijaya Kumar K
arch_kgdb_breakpoint(void)19bcf5763bSVijaya Kumar K static inline void arch_kgdb_breakpoint(void)
20bcf5763bSVijaya Kumar K {
217acf71d1SCatalin Marinas asm ("brk %0" : : "I" (KGDB_COMPILED_DBG_BRK_IMM));
22bcf5763bSVijaya Kumar K }
23bcf5763bSVijaya Kumar K
24bcf5763bSVijaya Kumar K extern void kgdb_handle_bus_error(void);
25bcf5763bSVijaya Kumar K extern int kgdb_fault_expected;
26bcf5763bSVijaya Kumar K
27bcf5763bSVijaya Kumar K #endif /* !__ASSEMBLY__ */
28bcf5763bSVijaya Kumar K
29bcf5763bSVijaya Kumar K /*
300d15ef67SDaniel Thompson * gdb remote procotol (well most versions of it) expects the following
310d15ef67SDaniel Thompson * register layout.
32bcf5763bSVijaya Kumar K *
33bcf5763bSVijaya Kumar K * General purpose regs:
34bcf5763bSVijaya Kumar K * r0-r30: 64 bit
35bcf5763bSVijaya Kumar K * sp,pc : 64 bit
360d15ef67SDaniel Thompson * pstate : 32 bit
370d15ef67SDaniel Thompson * Total: 33 + 1
38bcf5763bSVijaya Kumar K * FPU regs:
39bcf5763bSVijaya Kumar K * f0-f31: 128 bit
40bcf5763bSVijaya Kumar K * fpsr & fpcr: 32 bit
410d15ef67SDaniel Thompson * Total: 32 + 2
42bcf5763bSVijaya Kumar K *
430d15ef67SDaniel Thompson * To expand a little on the "most versions of it"... when the gdb remote
440d15ef67SDaniel Thompson * protocol for AArch64 was developed it depended on a statement in the
450d15ef67SDaniel Thompson * Architecture Reference Manual that claimed "SPSR_ELx is a 32-bit register".
460d15ef67SDaniel Thompson * and, as a result, allocated only 32-bits for the PSTATE in the remote
470d15ef67SDaniel Thompson * protocol. In fact this statement is still present in ARM DDI 0487A.i.
480d15ef67SDaniel Thompson *
490d15ef67SDaniel Thompson * Unfortunately "is a 32-bit register" has a very special meaning for
500d15ef67SDaniel Thompson * system registers. It means that "the upper bits, bits[63:32], are
510d15ef67SDaniel Thompson * RES0.". RES0 is heavily used in the ARM architecture documents as a
520d15ef67SDaniel Thompson * way to leave space for future architecture changes. So to translate a
530d15ef67SDaniel Thompson * little for people who don't spend their spare time reading ARM architecture
540d15ef67SDaniel Thompson * manuals, what "is a 32-bit register" actually means in this context is
550d15ef67SDaniel Thompson * "is a 64-bit register but one with no meaning allocated to any of the
560d15ef67SDaniel Thompson * upper 32-bits... *yet*".
570d15ef67SDaniel Thompson *
580d15ef67SDaniel Thompson * Perhaps then we should not be surprised that this has led to some
590d15ef67SDaniel Thompson * confusion. Specifically a patch, influenced by the above translation,
600d15ef67SDaniel Thompson * that extended PSTATE to 64-bit was accepted into gdb-7.7 but the patch
610d15ef67SDaniel Thompson * was reverted in gdb-7.8.1 and all later releases, when this was
620d15ef67SDaniel Thompson * discovered to be an undocumented protocol change.
630d15ef67SDaniel Thompson *
640d15ef67SDaniel Thompson * So... it is *not* wrong for us to only allocate 32-bits to PSTATE
650d15ef67SDaniel Thompson * here even though the kernel itself allocates 64-bits for the same
660d15ef67SDaniel Thompson * state. That is because this bit of code tells the kernel how the gdb
670d15ef67SDaniel Thompson * remote protocol (well most versions of it) describes the register state.
680d15ef67SDaniel Thompson *
690d15ef67SDaniel Thompson * Note that if you are using one of the versions of gdb that supports
700d15ef67SDaniel Thompson * the gdb-7.7 version of the protocol you cannot use kgdb directly
710d15ef67SDaniel Thompson * without providing a custom register description (gdb can load new
720d15ef67SDaniel Thompson * protocol descriptions at runtime).
73bcf5763bSVijaya Kumar K */
74bcf5763bSVijaya Kumar K
750d15ef67SDaniel Thompson #define _GP_REGS 33
76bcf5763bSVijaya Kumar K #define _FP_REGS 32
770d15ef67SDaniel Thompson #define _EXTRA_REGS 3
78bcf5763bSVijaya Kumar K /*
79bcf5763bSVijaya Kumar K * general purpose registers size in bytes.
80bcf5763bSVijaya Kumar K * pstate is only 4 bytes. subtract 4 bytes
81bcf5763bSVijaya Kumar K */
82bcf5763bSVijaya Kumar K #define GP_REG_BYTES (_GP_REGS * 8)
83bcf5763bSVijaya Kumar K #define DBG_MAX_REG_NUM (_GP_REGS + _FP_REGS + _EXTRA_REGS)
84bcf5763bSVijaya Kumar K
85bcf5763bSVijaya Kumar K /*
86bcf5763bSVijaya Kumar K * Size of I/O buffer for gdb packet.
87bcf5763bSVijaya Kumar K * considering to hold all register contents, size is set
88bcf5763bSVijaya Kumar K */
89bcf5763bSVijaya Kumar K
90bcf5763bSVijaya Kumar K #define BUFMAX 2048
91bcf5763bSVijaya Kumar K
92bcf5763bSVijaya Kumar K /*
93bcf5763bSVijaya Kumar K * Number of bytes required for gdb_regs buffer.
94bcf5763bSVijaya Kumar K * _GP_REGS: 8 bytes, _FP_REGS: 16 bytes and _EXTRA_REGS: 4 bytes each
95bcf5763bSVijaya Kumar K * GDB fails to connect for size beyond this with error
96bcf5763bSVijaya Kumar K * "'g' packet reply is too long"
97bcf5763bSVijaya Kumar K */
98bcf5763bSVijaya Kumar K
99bcf5763bSVijaya Kumar K #define NUMREGBYTES ((_GP_REGS * 8) + (_FP_REGS * 16) + \
100bcf5763bSVijaya Kumar K (_EXTRA_REGS * 4))
101bcf5763bSVijaya Kumar K
102bcf5763bSVijaya Kumar K #endif /* __ASM_KGDB_H */
103