code review 144180043: runtime: skip TestBreakpoint on arm

runtime: skip TestBreakpoint on arm

Update issue 8775

Issuing a bkpt instruction on the armv5 builder causes the test binary to spin. This suggests either the kernel or the hardware can't handle this properly.

This CL disables the test on all arm devices as runtime.goarm is not available to Go code at the moment. I'll try to address this limitation and skip the test only on GOARM=5 machines in a followup CL once this builder is passing.

[dave_cheney.net, 2014-09-19 07:23:16]

Hello golang-codereviews@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go

[brainman, 2014-09-19 07:26:41]

LGTM

[minux, 2014-09-19 16:01:36]

I think we should fix runtime.Breakpoint instead (e.g. using kill(getpid(),
SIGTRAP) for goarm == 5?)

What does gdb use for software breakpoints on armv5? perhaps we just need
to use another instruction.

[iant, 2014-09-19 18:11:38]

On Fri, Sep 19, 2014 at 9:01 AM, minux <minux@golang.org> wrote:
>
> What does gdb use for software breakpoints on armv5? perhaps we just need to
> use another instruction.

As far as I can tell gdb always uses an undefined instruction as a
breakpoint on ARM GNU/Linux systems.  The little-endian version is
.word 0xe7f001f0.  The comment in gdb/arm-linux-tdep.c says:

/* However, the EABI syscall interface (new in Nov. 2005) does not look at
   the operand of the swi if old-ABI compatibility is disabled.  Therefore,
   use an undefined instruction instead.  This is supported as of kernel
   version 2.5.70 (May 2003), so should be a safe assumption for EABI
   binaries.  */

On non-GNU/Linux systems gdb uses .word 0xe7ffdefe.  The comment in
gdb/arm-tdep.c says:

/* The following define instruction sequences that will cause ARM
   cpu's to take an undefined instruction trap.  These are used to
   signal a breakpoint to GDB.

   The newer ARMv4T cpu's are capable of operating in ARM or Thumb
   modes.  A different instruction is required for each mode.  The ARM
   cpu's can also be big or little endian.  Thus four different
   instructions are needed to support all cases.

   Note: ARMv4 defines several new instructions that will take the
   undefined instruction trap.  ARM7TDMI is nominally ARMv4T, but does
   not in fact add the new instructions.  The new undefined
   instructions in ARMv4 are all instructions that had no defined
   behaviour in earlier chips.  There is no guarantee that they will
   raise an exception, but may be treated as NOP's.  In practice, it
   may only safe to rely on instructions matching:

   3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
   C C C C 0 1 1 x x x x x x x x x x x x x x x x x x x x 1 x x x x

   Even this may only true if the condition predicate is true.  The
   following use a condition predicate of ALWAYS so it is always TRUE.

   There are other ways of forcing a breakpoint.  GNU/Linux, RISC iX,
   and NetBSD all use a software interrupt rather than an undefined
   instruction to force a trap.  This can be handled by by the
   abi-specific code during establishment of the gdbarch vector.  */

Ian

[dave_cheney.net, 2014-09-23 01:30:22]

Hi Minux,

On frustration in fixing this issue is goarm is not available on the
go side in the runtime package, and it'll probably be simpler if it
stays that way.

I'll try Ian's suggestion of using a different breakpoint instructions
on goarm == 5 and see if that makes an improvement.

On Sat, Sep 20, 2014 at 2:01 AM, minux <minux@golang.org> wrote:
> I think we should fix runtime.Breakpoint instead (e.g. using kill(getpid(),
> SIGTRAP) for goarm == 5?)
>
> What does gdb use for software breakpoints on armv5? perhaps we just need to
> use another instruction.

[dave_cheney.net, 2014-09-23 01:34:31]

*** Abandoned ***