include/asm/kgdb.h

0001 /* SPDX-License-Identifier: GPL-2.0-only */
0002 /*
0003  * AArch64 KGDB support
0004  *
0005  * Based on arch/arm/include/kgdb.h
0006  *
0007  * Copyright (C) 2013 Cavium Inc.
0008  * Author: Vijaya Kumar K <vijaya.kumar@caviumnetworks.com>
0009  */
0010
0011 #ifndef __ARM_KGDB_H
0012 #define __ARM_KGDB_H
0013
0014 #include <linux/ptrace.h>
0015 #include <asm/debug-monitors.h>
0016
0017 #ifndef __ASSEMBLY__
0018
0019 static inline void arch_kgdb_breakpoint(void)
0020 {
0021     asm ("brk %0" : : "I" (KGDB_COMPILED_DBG_BRK_IMM));
0022 }
0023
0024 extern void kgdb_handle_bus_error(void);
0025 extern int kgdb_fault_expected;
0026
0027 #endif /* !__ASSEMBLY__ */
0028
0029 /*
0030  * gdb remote procotol (well most versions of it) expects the following
0031  * register layout.
0032  *
0033  * General purpose regs:
0034  *     r0-r30: 64 bit
0035  *     sp,pc : 64 bit
0036  *     pstate  : 32 bit
0037  *     Total: 33 + 1
0038  * FPU regs:
0039  *     f0-f31: 128 bit
0040  *     fpsr & fpcr: 32 bit
0041  *     Total: 32 + 2
0042  *
0043  * To expand a little on the "most versions of it"... when the gdb remote
0044  * protocol for AArch64 was developed it depended on a statement in the
0045  * Architecture Reference Manual that claimed "SPSR_ELx is a 32-bit register".
0046  * and, as a result, allocated only 32-bits for the PSTATE in the remote
0047  * protocol. In fact this statement is still present in ARM DDI 0487A.i.
0048  *
0049  * Unfortunately "is a 32-bit register" has a very special meaning for
0050  * system registers. It means that "the upper bits, bits[63:32], are
0051  * RES0.". RES0 is heavily used in the ARM architecture documents as a
0052  * way to leave space for future architecture changes. So to translate a
0053  * little for people who don't spend their spare time reading ARM architecture
0054  * manuals, what "is a 32-bit register" actually means in this context is
0055  * "is a 64-bit register but one with no meaning allocated to any of the
0056  * upper 32-bits... *yet*".
0057  *
0058  * Perhaps then we should not be surprised that this has led to some
0059  * confusion. Specifically a patch, influenced by the above translation,
0060  * that extended PSTATE to 64-bit was accepted into gdb-7.7 but the patch
0061  * was reverted in gdb-7.8.1 and all later releases, when this was
0062  * discovered to be an undocumented protocol change.
0063  *
0064  * So... it is *not* wrong for us to only allocate 32-bits to PSTATE
0065  * here even though the kernel itself allocates 64-bits for the same
0066  * state. That is because this bit of code tells the kernel how the gdb
0067  * remote protocol (well most versions of it) describes the register state.
0068  *
0069  * Note that if you are using one of the versions of gdb that supports
0070  * the gdb-7.7 version of the protocol you cannot use kgdb directly
0071  * without providing a custom register description (gdb can load new
0072  * protocol descriptions at runtime).
0073  */
0074
0075 #define _GP_REGS        33
0076 #define _FP_REGS        32
0077 #define _EXTRA_REGS     3
0078 /*
0079  * general purpose registers size in bytes.
0080  * pstate is only 4 bytes. subtract 4 bytes
0081  */
0082 #define GP_REG_BYTES        (_GP_REGS * 8)
0083 #define DBG_MAX_REG_NUM     (_GP_REGS + _FP_REGS + _EXTRA_REGS)
0084
0085 /*
0086  * Size of I/O buffer for gdb packet.
0087  * considering to hold all register contents, size is set
0088  */
0089
0090 #define BUFMAX          2048
0091
0092 /*
0093  * Number of bytes required for gdb_regs buffer.
0094  * _GP_REGS: 8 bytes, _FP_REGS: 16 bytes and _EXTRA_REGS: 4 bytes each
0095  * GDB fails to connect for size beyond this with error
0096  * "'g' packet reply is too long"
0097  */
0098
0099 #define NUMREGBYTES ((_GP_REGS * 8) + (_FP_REGS * 16) + \
0100             (_EXTRA_REGS * 4))
0101
0102 #endif /* __ASM_KGDB_H */