Re: code review 6442109: runtime: abort on $GOARM mismatch (issue 6442109)

[r...@golang.org]

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c
File src/pkg/runtime/runtime.c (right):

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c#newcode214
src/pkg/runtime/runtime.c:214: if(runtime·armArch < runtime·goarm) {
Where is armArch being set?

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c#newcode215
src/pkg/runtime/runtime.c:215: runtime·printf("This binary requires
ARMv%d, this host is ARMv%d.\n",
"runtime: cannot run ARMv%d binary on ARMv%d system\n",

http://codereview.appspot.com/6442109/

[minu...@gmail.com]

On 2012/08/30 14:46:44, rsc wrote:
http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c#newcode214
> src/pkg/runtime/runtime.c:214: if(runtime·armArch < runtime·goarm) {
> Where is armArch being set?

http://tip.golang.org/src/pkg/runtime/signal_linux_arm.c#L178

Russ, could you please take a look at the corresponding golang-dev
discussion?

http://codereview.appspot.com/6442109/

[da...@cheney.net]

Thank you for your comments, PTAL.

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c
File src/pkg/runtime/runtime.c (right):

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c#newcode214
src/pkg/runtime/runtime.c:214: if(runtime·armArch < runtime·goarm) {
On 2012/08/30 14:46:44, rsc wrote:
> Where is armArch being set?

signal_linux_arm.c +178

I might be able to move them closer together if you would like.

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c#newcode215
src/pkg/runtime/runtime.c:215: runtime·printf("This binary requires
ARMv%d, this host is ARMv%d.\n",

On 2012/08/30 14:46:44, rsc wrote:

> "runtime: cannot run ARMv%d binary on ARMv%d system\n",

Done.

http://codereview.appspot.com/6442109/

[minux]

sorry, but i tend to oppose this approach now.

as elaborated here: https://groups.google.com/d/topic/golang-dev/WqJuNnZr8pw/discussion

i think this approach unnecessarily limit the scope of our binaries. this will make it

difficult for our developers to distribute pre-built binaries (either he must provide ARMv5

version and sacrifice floating point performance or he provide at least ARMv5 and ARMv6

versions, but user with VFP-less ARMv6 will have to use the ARMv5 version, which is

counter-intuitive at least);

we've spend quite some effort in the runtime to auto detect architecture and use

the best available instructions for synchronization. I think we can do better for this case.

our Go binary really only need two flavors, one with software floating point (undoubtedly could

be run on all supported machines), and one with VFPv1 hardware floating point.

to sum up, i'd rather disable VFPv3-only vmov (imm) instruction entirely than this approach.

ps:

$GOARM is somewhat misnamed, i think GOVFP would be much better.

if we can introduce GOVFP (or something similar), we can use this approach for it, because

it is less confusing to the users (our GOARM isn't really related to ARM Architecture).

[Dave Cheney]

In the spirit of supporting the Pi by Go 1.1, I would support removing vmov imm at this point and revisiting it later. I have a benchmark that shows in the micro there is a significant cost on arm7  without vmov imm for the math package, but it is hard to find a serious impact in the macro go1 benchmarks. 

[minux]

On Sat, Sep 1, 2012 at 4:38 PM, Dave Cheney <da...@cheney.net> wrote:

In the spirit of supporting the Pi by Go 1.1, I would support removing vmov imm at this point and revisiting it later. I have a benchmark that shows in the micro there is a significant cost on arm7  without vmov imm for the math package, but it is hard to find a serious impact in the macro go1 benchmarks. 

vmov imm doesn't do much (it can only load a specific class of constant floating

point numbers), i think maybe we can rewrite some code in the math package to

solve the performance issue.

[Dave Cheney]

SGTM. 

[Russ Cox]

I would still like to see a runtime check that can print:

runtime: cannot run GOARM=%d binary on this system; need GOARM=%d

because it is a common source of problems for people. Don't make any
reference to the "ARM version", just to the GOARM setting. That
definition is purely under our control.

Russ

[Dave Cheney]

rsc: I have updated the error message in runtime.c, PTAL

all: I think we can do both, print an error message on GOARM mismatch,
and also stop using vmov imm (which restricts the range of GOARM
values to 5 and 6) for the moment.

[minu...@gmail.com]

i need to do some experiments regarding hard floating point
and kernel software floating point emulation.

maybe we can make both GOARM=5 and GOARM=6 runnable
on most systems.
(GOARM=5 obviously can be run on VFP systems, only slower.
i think GOARM=6 might be able to run VFP-less systems, provided
kernel softfp is enabled [it should be enabled by default on
most systems])

if it's the case, our job is more difficult, but the life will be much
easier for user:
we need to detect whether the kernel can actually run this binary
correctly (maybe slow), and if it's, let it run. if it's not, give error
and exit.



http://codereview.appspot.com/6442109/diff/16007/src/pkg/runtime/runtime.c
File src/pkg/runtime/runtime.c (right):

http://codereview.appspot.com/6442109/diff/16007/src/pkg/runtime/runtime.c#newcode214

src/pkg/runtime/runtime.c:214: if(runtime·armArch < runtime·goarm) {

if we only differentiate GOARM=5 (soft float) and GOARM>5 (VFP),
i think you'd better use runtime.hwcap & HWCAP_VFP instead.

FYI, HWCAP_VFP is defined in /usr/include/asm/hwcap.h.

http://codereview.appspot.com/6442109/

[minux]

On Mon, Sep 3, 2012 at 3:19 AM, <minu...@gmail.com> wrote:

i need to do some experiments regarding hard floating point
and kernel software floating point emulation.

unfortunately, the nwfpe software floating point facility in kernel is

only capable of emulating fpa (not vfp) instructions, so universal

arm binary is still not possible.