Patchwork [PATCH/AARCH64] Emit brk #0 for __builtin_trap

login
register
mail settings
Submitter Andrew Pinski
Date Nov. 13, 2013, 12:04 a.m.
Message ID <CA+=Sn1nrT-i4CC=wH-LxSKWhv5Qspt3NOWpuucg6-Gz2s78PwQ@mail.gmail.com>
Download mbox | patch
Permalink /patch/290801/
State New
Headers show

Comments

Andrew Pinski - Nov. 13, 2013, 12:04 a.m.
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.

OK?  Build and tested on aarch64-elf with no regressions.  Also built
a full aarch64-linux-gnu toolchain including glibc.

Thanks,
Andrew Pinski

ChangeLog:

* config/aarch64/aarch64.md (trap): New pattern.
Marcus Shawcroft - Nov. 19, 2013, 9:22 a.m.
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
Andrew Pinski - Nov. 19, 2013, 9:24 p.m.
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
>

Patch

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))]
   ""