123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102 |
- /* SPDX-License-Identifier: GPL-2.0-only */
- /*
- * AArch64 KGDB support
- *
- * Based on arch/arm/include/kgdb.h
- *
- * Copyright (C) 2013 Cavium Inc.
- * Author: Vijaya Kumar K <[email protected]>
- */
- #ifndef __ARM_KGDB_H
- #define __ARM_KGDB_H
- #include <linux/ptrace.h>
- #include <asm/debug-monitors.h>
- #ifndef __ASSEMBLY__
- static inline void arch_kgdb_breakpoint(void)
- {
- asm ("brk %0" : : "I" (KGDB_COMPILED_DBG_BRK_IMM));
- }
- extern void kgdb_handle_bus_error(void);
- extern int kgdb_fault_expected;
- #endif /* !__ASSEMBLY__ */
- /*
- * gdb remote procotol (well most versions of it) expects the following
- * register layout.
- *
- * General purpose regs:
- * r0-r30: 64 bit
- * sp,pc : 64 bit
- * pstate : 32 bit
- * Total: 33 + 1
- * FPU regs:
- * f0-f31: 128 bit
- * fpsr & fpcr: 32 bit
- * Total: 32 + 2
- *
- * To expand a little on the "most versions of it"... when the gdb remote
- * protocol for AArch64 was developed it depended on a statement in the
- * Architecture Reference Manual that claimed "SPSR_ELx is a 32-bit register".
- * and, as a result, allocated only 32-bits for the PSTATE in the remote
- * protocol. In fact this statement is still present in ARM DDI 0487A.i.
- *
- * Unfortunately "is a 32-bit register" has a very special meaning for
- * system registers. It means that "the upper bits, bits[63:32], are
- * RES0.". RES0 is heavily used in the ARM architecture documents as a
- * way to leave space for future architecture changes. So to translate a
- * little for people who don't spend their spare time reading ARM architecture
- * manuals, what "is a 32-bit register" actually means in this context is
- * "is a 64-bit register but one with no meaning allocated to any of the
- * upper 32-bits... *yet*".
- *
- * Perhaps then we should not be surprised that this has led to some
- * confusion. Specifically a patch, influenced by the above translation,
- * that extended PSTATE to 64-bit was accepted into gdb-7.7 but the patch
- * was reverted in gdb-7.8.1 and all later releases, when this was
- * discovered to be an undocumented protocol change.
- *
- * So... it is *not* wrong for us to only allocate 32-bits to PSTATE
- * here even though the kernel itself allocates 64-bits for the same
- * state. That is because this bit of code tells the kernel how the gdb
- * remote protocol (well most versions of it) describes the register state.
- *
- * Note that if you are using one of the versions of gdb that supports
- * the gdb-7.7 version of the protocol you cannot use kgdb directly
- * without providing a custom register description (gdb can load new
- * protocol descriptions at runtime).
- */
- #define _GP_REGS 33
- #define _FP_REGS 32
- #define _EXTRA_REGS 3
- /*
- * general purpose registers size in bytes.
- * pstate is only 4 bytes. subtract 4 bytes
- */
- #define GP_REG_BYTES (_GP_REGS * 8)
- #define DBG_MAX_REG_NUM (_GP_REGS + _FP_REGS + _EXTRA_REGS)
- /*
- * Size of I/O buffer for gdb packet.
- * considering to hold all register contents, size is set
- */
- #define BUFMAX 2048
- /*
- * Number of bytes required for gdb_regs buffer.
- * _GP_REGS: 8 bytes, _FP_REGS: 16 bytes and _EXTRA_REGS: 4 bytes each
- * GDB fails to connect for size beyond this with error
- * "'g' packet reply is too long"
- */
- #define NUMREGBYTES ((_GP_REGS * 8) + (_FP_REGS * 16) + \
- (_EXTRA_REGS * 4))
- #endif /* __ASM_KGDB_H */
|