On 19.06.2019 06:41, maya%netbsd.org@localhost wrote: > On Tue, Jun 18, 2019 at 09:18:13PM +0000, Kamil Rytarowski wrote: >> Module Name: src >> Committed By: kamil >> Date: Tue Jun 18 21:18:13 UTC 2019 >> >> Modified Files: >> src/sys/arch/aarch64/include: ptrace.h >> src/sys/arch/alpha/include: ptrace.h >> src/sys/arch/amd64/include: ptrace.h >> src/sys/arch/arm/include: ptrace.h >> src/sys/arch/hppa/include: ptrace.h >> src/sys/arch/i386/include: ptrace.h >> src/sys/arch/ia64/include: ptrace.h >> src/sys/arch/m68k/include: ptrace.h >> src/sys/arch/mips/include: ptrace.h >> src/sys/arch/or1k/include: ptrace.h >> src/sys/arch/powerpc/include: ptrace.h >> src/sys/arch/riscv/include: ptrace.h >> src/sys/arch/sh3/include: ptrace.h >> src/sys/arch/sparc/include: ptrace.h >> src/sys/arch/vax/include: ptrace.h >> >> Log Message: >> Introduce PTRACE_REG_FP() a helper macro to retrieve the frame pointer >> >> The macro is dummy for ia64 (the FP register is unknown and can change >> freely) and sparc/sparc64 (not stored in struct reg). > > Wouldn't it be better not to declare PTRACE_REG_FP for the cases where > obtaining it is more complicated? > > e.g. someone who hasn't seen this commit and wants to use PTRACE_REG_FP > thinks that they can just use it, and until they specifically test ia64 > and sparc64 they won't know it doesn't behave correctly. > FP isn't reliable on any platform so every person has to be prepared. For meaningful backtraces there is need to use DWARF or CTF. Returning 0 doesn't make it much worse than on other CPUs. It's used in simpler debuggers (my use-case is edb-debugger) and in tests mainly.
Attachment:
signature.asc
Description: OpenPGP digital signature