| Message ID | CA+=Sn1nrT-i4CC=wH-LxSKWhv5Qspt3NOWpuucg6-Gz2s78PwQ@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 13 November 2013 00:04, Andrew Pinski <andrew.pinski@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
On Tue, Nov 19, 2013 at 1:22 AM, Marcus Shawcroft <marcus.shawcroft@arm.com> wrote: > On 13 November 2013 00:04, Andrew Pinski > > <andrew.pinski@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 >
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md index 758be47..10b2fc5 100644 --- a/gcc/config/aarch64/aarch64.md +++ b/gcc/config/aarch64/aarch64.md @@ -453,6 +453,11 @@ [(set_attr "v8type" "misc")] ) +(define_insn "trap" + [(trap_if (const_int 1) (const_int 8))] + "" + "brk #0") + (define_expand "prologue" [(clobber (const_int 0))] ""