On 13 November 2013 00:04, Andrew Pinski
<andrew.pin...@caviumnetworks.com> wrote:
Hi all,
This patch implements the trap pattern for the AARCH64 back-end. I
used the "brk #0" instruction as that is the breakpoint instruction
that GDB uses. I looked at what other targets did when the
instruction set did not have a trap instruction and found that using
the breakpoint instruction was a common theme between them if there
was not explicit defined undefined instruction to use.
Hi Andrew, We can exploit the immediate field in the brk instruction to
distinguish the origin of various traps. There was some discussion on
this topic within ARM a (long) while back, at that time we discussed a
scheme along the following lines:
POSIX siginfo
BRK #imm16 si_signo si_code Purpose
---------- -------- ------- -------
0000-0fff S/w breakpoint, reserved for debuggers
0000-3ff SIGTRAP TRAP_BRKPT- EL0 breakpoint (e.g. gdb)
0400-7ff SIGILL ILL_ILLTRP* EL1 breakpoint (e.g. kgdb)
0800-bff SIGILL ILL_ILLTRP* EL2 breakpoint
0c00-fff SIGILL ILL_ILLTRP* EL3 breakpoint
1000-1fff C/C++ runtime errors
1000 SIGABRT n/a libc abort()
1001 SIGFPE FPE_INTDIV integer divide by zero
1002 SIGFPE FPE_INTOVF integer overflow
1003 SIGFPE FPE_FLTDIV floating-point divide by zero
1004 SIGFPE FPE_FLTOVF floating-point overflow
1005 SIGFPE FPE_FLTUND floating-point underflow
1006 SIGFPE FPE_FLTRES floating-point inexact result
1007 SIGFPE FPE_FLTINV floating-point invalid op
1008 SIGFPE FPE_FLTSUB subscript out of range
1009-1fff SIGILL ILL_ILLTRP unused but reserved
2000-ffff SIGILL ILL_ILLOPC+ Guaranteed unused, resvd for apps
- This is the signal generated now for all values of BRK
immediate. GDB currently uses "BRK #0"
* The EL1/EL2/EL3 breakpoints would deliver a SIGILL if they are
executed by EL0 code, and caught by the EL1 kernel. A s/w debugger
operating at a higher EL which placed such breakpoints would
presumably catch them and handle them, without the EL1 kernel ever
seeing them.
+ Immediate values 0x2000-ffff generate the same signal as any other
UNDEFINED instruction encoding, but with guaranteed behaviour for
JITs etc. The original imm16 value could be made available in the
si_trapno field of the signal context.
Following this scheme I suggest __builtin_trap() generate brk #1000
Thoughts?
Cheers
/Marcus
