On Tue, Nov 19, 2013 at 1:22 AM, Marcus Shawcroft <marcus.shawcr...@arm.com> wrote: > 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?
This sounds like a good scheme. I will update my patch to use #1000 based on this. Thanks, Andrew Pinski > > Cheers > /Marcus >
