runtime: give better diagnostic when it should be compiled with GOARM=5

[gopherbot]

by justin@specialbusservice.com:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull", "hg update default", rebuild, and
retry
what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. Build a binary file or use go command
2. run it

What is the expected output?
Program should run

What do you see instead?
./5.out 
This program can only be run on EABI kernels


Which compiler are you using (5g, 6g, 8g, gccgo)?
5g

Which operating system are you using?
Linux

Which revision are you using?  (hg identify)
a303acb0a5f2 tip


Please provide any additional information below.

My ARM machine is using AEABI, /proc/config.gz has:

CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set

However the test code in ./src/pkg/runtime/rt0_linux_arm.s is somehow failing apparently.

If I comment out the test syscalls in that file, everything runs fine, so somehow this
test breaks on my CPU.

(Oddly, the tests in build do pass, which is odd and confused me).

/proc/cpuinfo

cat /proc/cpuinfo
Processor   : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS    : 1191.11
Features    : swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part    : 0x131
CPU revision    : 1

Hardware    : Marvell GuruPlug Reference Board
Revision    : 0000
Serial      : 0000000000000000

[gopherbot]

Comment 1 by justin@specialbusservice.com:

Note this is compiled with GOARM=5. All fine on my other ARM machine that is a more
recent architecture.

[minux]

Comment 2:

Could you please give some detail on what did you comment out in rt0_linux_arm.s to make
your program run again?
Also, if your test program are not compiled with GOARM=5, will it run?

Status changed to WaitingForReply.

[gopherbot]

Comment 3 by justin@specialbusservice.com:

I commented out both syscalls:
        // set up sa_handler
        MOVW    $bad_abi<>(SB), R0 // sa_handler
        MOVW    $0, R1 // sa_flags
        MOVW    $0, R2 // sa_restorer
        MOVW    $0, R3 // sa_mask
        MOVM.DB.W [R0-R3], (R13)
        MOVW    $4, R0 // SIGILL
        MOVW    R13, R1 // sa
        MOVW    $0, R2 // old_sa
        MOVW    $8, R3 // c
        MOVW    $174, R7 // sys_sigaction
        //BL    oabi_syscall<>(SB)
        ADD     $16, R13
        // do an EABI syscall
        MOVW    $20, R7 // sys_getpid
        //SWI   $0 // this will trigger SIGILL on OABI systems
        B       _rt0_arm(SB)
In terms of compiling with GOARM=5, I thought this was a build time setting not for each
compilation? Or have I got this wrong? I can't build for this system without that set,
as it is an old ARM. If it is a compile time setting then possibly it was not set, can
re-check.

[gopherbot]

Comment 4 by justin@specialbusservice.com:

Scratch this, I did a clean build from baeb068aac25 tip and did not have this issue.
Assume something was broken with the build with respect to GOARM setting or similar.
Suspicious as the tests did run ok, but my program did not, suspect was using the wrong
compiler?

[minux]

Comment 5:

We do have a few issues about SIGILL on ARMv5 hardware, like issue #2261 and issue #3331,
but
I think the OABI tests is OK (although SIGILL happens before proper SIGILL handler is
registered
will display the OABI warning, which is wrong, and I will fix it).

Owner changed to @minux.

Status changed to Accepted.

[dsymonds]

Comment 7:

Labels changed: added priority-later, arch-arm, removed priority-triage.

[rsc]

Comment 8:

Status changed to Retracted.

[minux]

Comment 9:

runtime.check() uses floating point instructions, so on a FPU-less machine that can't
emulate these 
instruction it will trigger SIGILL before runtime could setup signal handers properly,
and the binary
will display "This program can only be run on EABI kernels", which is misleading.
I must admit, even if this issue is fixed, the message produced for this situation
(Illegal instruction)
isn't very helpful either (but at least not misleading, and we can tell people if that
occurs, you should
relink with GOARM=5). We still need to address the FPA instruction issue.

Status changed to Accepted.

[gopherbot]

Comment 10 by justin@specialbusservice.com:

Ah that makes sense. I don't know my ARM assembly well enough yet. Personally I would
have been very happy with a SIGILL. The EABI result was so confusing as as far as I know
nothing uses the old ABI, so that simply wasnt the problem. I guess if you were very
nice you could set up a SIGILL handler at the beginning of any non GOARM=5 executable
and then run a bunch of instructions that are not supported on old architectures, and
report a helpful error, then carry on to the existing test...

[minux]

Comment 12:

Or better, get rid of remaining FPA instructions, so that the kernel could emulate them
for us.
(issue #3456)

[rsc]

Comment 13:

It is fine to postpone check to later in the runtime startup.

[minux]

Comment 14:

Issue #3911 has been merged into this issue.

[rsc]

Comment 15:

Labels changed: added go1.1.

[minux]

Comment 16:

this is fixed by rev e4b20018f797 and rev bfad57cc7171.

Status changed to Fixed.