all: support for NetBSD/ARM (*NOT FOR SUBMISSION*)

all: support for NetBSD/ARM (*NOT FOR SUBMISSION*)
cgo is supported in patch set 3.

hint: 
1. use latest kernel from NetBSD-current with a
prebuilt SD-card image (2GiB card is enough).
2. either apply the patch [2] in comment #4 to NetBSD
gcc or sed -i -e 's/-O2/-O1/' cmd/dist/build.c

[dave_cheney.net, 2013-02-01 01:21:55]

I'm building this patch now, albeit slowly.

https://codereview.appspot.com/7227066/diff/3/src/cmd/dist/arm.c
File src/cmd/dist/arm.c (right):

https://codereview.appspot.com/7227066/diff/3/src/cmd/dist/arm.c#newcode20
src/cmd/dist/arm.c:20: return "5";
Did this cause the kernel to panic ?

https://codereview.appspot.com/7227066/diff/3/src/cmd/dist/build.c
File src/cmd/dist/build.c (right):

https://codereview.appspot.com/7227066/diff/3/src/cmd/dist/build.c#newcode411
src/cmd/dist/build.c:411: "-O0",
Please revert this

https://codereview.appspot.com/7227066/diff/3/src/pkg/runtime/rt0_netbsd_arm.s
File src/pkg/runtime/rt0_netbsd_arm.s (right):

https://codereview.appspot.com/7227066/diff/3/src/pkg/runtime/rt0_netbsd_arm....
src/pkg/runtime/rt0_netbsd_arm.s:5: // FreeBSD/NetBSD and Linux use the same
linkage to main
Maybe use a // +build tag here ? Maybe it isn't worth it, this is just one
branch during startup.

https://codereview.appspot.com/7227066/diff/3/src/pkg/syscall/asm_netbsd_arm.s
File src/pkg/syscall/asm_netbsd_arm.s (right):

https://codereview.appspot.com/7227066/diff/3/src/pkg/syscall/asm_netbsd_arm....
src/pkg/syscall/asm_netbsd_arm.s:110: MOVW $16(FP), R13 // a4 to a9 are passed
on stack
a4 to a6

[dave_cheney.net, 2013-02-01 01:44:32]

I got throught bootstrap and built cmd/go, but after that I started getting read
and write errors on the sdcard. I think we have to wait for a more stable image
for the RPi.

I think your changes are good to apply, once you've rolled back the -O0 and arm
detect changes.

[minux1, 2013-02-02 16:54:44]

I just got a very very stable NetBSD kernel built, and it performed really
well
that I even finished the cgo port.

PTAL.

Just built the latest kernel (hint: you can build NetBSD kerne/userland on
almost every Unix, so no need to install NetBSD first. For example, I built
the kernel on Linux), and put the generated kernel.img to the fat32 /boot
partition (you can still use the latest pre-built sdcard image).

[minux1, 2013-02-02 22:51:29]

ok, this port is finally finished, and i think all.bash could pass now
(after enlarge some
time limits) and apply the patch (see [2] below).

in the past 6 hours, i was troubled by some mysterious test failures like
this:
--- FAIL: TestSprintf (0.03 seconds)
fmt_test.go:529:        Sprintf("%g", 1.2345675e+06) = "1.2345675e+06" want
"1.2345678e+06"
fmt_test.go:529:        Sprintf("%g", -7.000000000814907) =
"-7.000000000814907" want "-7"

it seems, somehow the softfloat code messed several lower bits of floating
point number.
i don't understand why, because our softfloat code is tested on every
platform, and then
i figured it could be due to a faulty gc.

and indeed, gc can't even correctly handle 1e10!
i don't understand this either, so i just lower the gcc optimization level
in cmd/dist from -O2
to -O0, and needless to say, the floating point bug disappeared.
After some lengthy debug, I was able to spot the following error in gcc's
generated code for
mpgetflt():
This C code snippet:
vm >>= 1;
f = (double)(vm);
// ...
Generates this under -O2:
 5dc:   e1b010a2        lsrs    r1, r2, #1
 5e0:   e1a00061        rrx     r0, r1 // obviously incorrect, as r1 is
just clobbered
 5e4:   eafffff5        b       5c0 <mpgetflt+0x240>
...
 5c0:   ebfffffe        bl      0 <__floatundidf>
 5c4:   e1a02007        mov     r2, r7
 5c8:   ebfffffe        bl      0 <ldexp>

After some digging inside gcc's RTL and comparing NetBSD's copy of gcc with
gcc trunk,
i found this patch [1] solved a similar issue in 2010.

what should we do about this? this bug isn't visible when compiled with
-O1, so maybe we
can do this?
diff -r 8696151130b7 src/cmd/dist/build.c
--- a/src/cmd/dist/build.c Sun Feb 03 02:36:46 2013 +0800
+++ b/src/cmd/dist/build.c Sun Feb 03 06:49:09 2013 +0800
@@ -408,7 +408,12 @@
  "-fno-common",
  "-ggdb",
  "-pipe",
+#ifdef __NetBSD__
+ // GCC 4.5.4 (NetBSD nb1 20120916) is known to mis-optimize gc/mparith3.c
+ "-O1",
+#else
  "-O2",
+#endif
 };

 static Vec gccargs;



[1] http://patchwork.ozlabs.org/patch/64562/
[2] patch for NetBSD src:
diff --git
a/external/gpl3/gcc/dist/gcc/config/arm/arm.mdb/external/gpl3/gcc/dist/gcc/config/arm/
arm.md
index 522e984..ac0144a 100644
--- a/external/gpl3/gcc/dist/gcc/config/arm/arm.md
+++ b/external/gpl3/gcc/dist/gcc/config/arm/arm.md
@@ -3189,7 +3189,7 @@
 )

 (define_insn "arm_ashldi3_1bit"
-  [(set (match_operand:DI            0 "s_register_operand" "=&r,r")
+  [(set (match_operand:DI            0 "s_register_operand" "=r,&r")
         (ashift:DI (match_operand:DI 1 "s_register_operand" "0,r")
                    (const_int 1)))
    (clobber (reg:CC CC_REGNUM))]
@@ -3248,7 +3248,7 @@
 )

 (define_insn "arm_ashrdi3_1bit"
-  [(set (match_operand:DI              0 "s_register_operand" "=&r,r")
+  [(set (match_operand:DI              0 "s_register_operand" "=r,&r")
         (ashiftrt:DI (match_operand:DI 1 "s_register_operand" "0,r")
                      (const_int 1)))
    (clobber (reg:CC CC_REGNUM))]
@@ -3304,7 +3304,7 @@
 )

 (define_insn "arm_lshrdi3_1bit"
-  [(set (match_operand:DI              0 "s_register_operand" "=&r,r")
+  [(set (match_operand:DI              0 "s_register_operand" "=r,&r")
         (lshiftrt:DI (match_operand:DI 1 "s_register_operand" "0,r")
                      (const_int 1)))
    (clobber (reg:CC CC_REGNUM))]

[dave_cheney.net, 2013-02-02 23:36:44]

> ok, this port is finally finished, and i think all.bash could pass now
> (after enlarge some
> time limits) and apply the patch (see [2] below).

Yes, I had to bump up a lot of the timeouts for freebsd/arm

#!/bin/bash

exec sh -c '
        export HOME=/u/builder
        export TMP=/tmp
        export TMPDIR=/tmp
        export GOARM=5
        WORK=/u/work
        TIMEOUT=120m
        exec $HOME/builder -v -buildroot=$WORK -cmdTimeout=$TIMEOUT
-buildTimeout=$TIMEOUT freebsd-arm-pi 2>&1
'

> in the past 6 hours, i was troubled by some mysterious test failures like
> this:
> --- FAIL: TestSprintf (0.03 seconds)
> fmt_test.go:529:        Sprintf("%g", 1.2345675e+06) = "1.2345675e+06" want
> "1.2345678e+06"
> fmt_test.go:529:        Sprintf("%g", -7.000000000814907) =
> "-7.000000000814907" want "-7"
>
> it seems, somehow the softfloat code messed several lower bits of floating
> point number.
> i don't understand why, because our softfloat code is tested on every
> platform, and then
> i figured it could be due to a faulty gc.
>
> and indeed, gc can't even correctly handle 1e10!
> i don't understand this either, so i just lower the gcc optimization level
> in cmd/dist from -O2
> to -O0, and needless to say, the floating point bug disappeared.
> After some lengthy debug, I was able to spot the following error in gcc's
> generated code for
> mpgetflt():
> This C code snippet:
> vm >>= 1;
> f = (double)(vm);
> // ...
> Generates this under -O2:
>  5dc:   e1b010a2        lsrs    r1, r2, #1
>  5e0:   e1a00061        rrx     r0, r1 // obviously incorrect, as r1 is just
> clobbered
>  5e4:   eafffff5        b       5c0 <mpgetflt+0x240>
> ...
>  5c0:   ebfffffe        bl      0 <__floatundidf>
>  5c4:   e1a02007        mov     r2, r7
>  5c8:   ebfffffe        bl      0 <ldexp>
>
> After some digging inside gcc's RTL and comparing NetBSD's copy of gcc with
> gcc trunk,
> i found this patch [1] solved a similar issue in 2010.

Wow, epic debugging win.

> what should we do about this? this bug isn't visible when compiled with -O1,
> so maybe we
> can do this?
> diff -r 8696151130b7 src/cmd/dist/build.c
> --- a/src/cmd/dist/build.c Sun Feb 03 02:36:46 2013 +0800
> +++ b/src/cmd/dist/build.c Sun Feb 03 06:49:09 2013 +0800
> @@ -408,7 +408,12 @@
>   "-fno-common",
>   "-ggdb",
>   "-pipe",
> +#ifdef __NetBSD__
> + // GCC 4.5.4 (NetBSD nb1 20120916) is known to mis-optimize gc/mparith3.c
> + "-O1",
> +#else
>   "-O2",
> +#endif
>  };

I am confused, but probably actually just uneducated, I thought that
all the BSDs had stuck with gcc 4.2.1, before the move to GPLv3. I
think there are two options, apply your patch above, or add a check to
./make.bash to fail the build if that version of gcc is the default.
The first is probably the easiest

Do you think there is value in creating a small test program, perhaps
in misc, that is compiled by dist that checks a few things like this.
We have a similar check inside the runtime that does sanity checks for
gc.

>  static Vec gccargs;
>
>
>
> [1] http://patchwork.ozlabs.org/patch/64562/
> [2] patch for NetBSD src:
> diff --git a/external/gpl3/gcc/dist/gcc/config/arm/arm.md
> b/external/gpl3/gcc/dist/gcc/config/arm/arm.md
> index 522e984..ac0144a 100644
> --- a/external/gpl3/gcc/dist/gcc/config/arm/arm.md
> +++ b/external/gpl3/gcc/dist/gcc/config/arm/arm.md
> @@ -3189,7 +3189,7 @@
>  )
>
>  (define_insn "arm_ashldi3_1bit"
> -  [(set (match_operand:DI            0 "s_register_operand" "=&r,r")
> +  [(set (match_operand:DI            0 "s_register_operand" "=r,&r")
>          (ashift:DI (match_operand:DI 1 "s_register_operand" "0,r")
>                     (const_int 1)))
>     (clobber (reg:CC CC_REGNUM))]
> @@ -3248,7 +3248,7 @@
>  )
>
>  (define_insn "arm_ashrdi3_1bit"
> -  [(set (match_operand:DI              0 "s_register_operand" "=&r,r")
> +  [(set (match_operand:DI              0 "s_register_operand" "=r,&r")
>          (ashiftrt:DI (match_operand:DI 1 "s_register_operand" "0,r")
>                       (const_int 1)))
>     (clobber (reg:CC CC_REGNUM))]
> @@ -3304,7 +3304,7 @@
>  )
>
>  (define_insn "arm_lshrdi3_1bit"
> -  [(set (match_operand:DI              0 "s_register_operand" "=&r,r")
> +  [(set (match_operand:DI              0 "s_register_operand" "=r,&r")
>          (lshiftrt:DI (match_operand:DI 1 "s_register_operand" "0,r")
>                       (const_int 1)))
>     (clobber (reg:CC CC_REGNUM))]
>

You mentioned you had access to a newer kernel image than the one
available on the RPi website which resolved the sd card issues, can
you show me where to get that kernel ?

[minux1, 2013-02-03 17:36:33]

I'm just amazed by the fact that enabling cgo together with GOARM=6 can
crash
the kernel.
However, one can enable either one of those two features (but not both)
without
any trouble.

i have a ugly hack (workarounds) for all these problems in cmd/dist here:
https://codereview.appspot.com/7286044/
but I will try to contact NetBSD team to fix the two bugs before mailing
that
bag of ugly hacks.

On Sun, Feb 3, 2013 at 7:36 AM, Dave Cheney <dave@cheney.net> wrote:

> > what should we do about this? this bug isn't visible when compiled with
> -O1,
> > so maybe we
> > can do this?
> > diff -r 8696151130b7 src/cmd/dist/build.c
> > --- a/src/cmd/dist/build.c Sun Feb 03 02:36:46 2013 +0800
> > +++ b/src/cmd/dist/build.c Sun Feb 03 06:49:09 2013 +0800
> > @@ -408,7 +408,12 @@
> >   "-fno-common",
> >   "-ggdb",
> >   "-pipe",
> > +#ifdef __NetBSD__
> > + // GCC 4.5.4 (NetBSD nb1 20120916) is known to mis-optimize
> gc/mparith3.c
> > + "-O1",
> > +#else
> >   "-O2",
> > +#endif
> >  };
>
> I am confused, but probably actually just uneducated, I thought that
> all the BSDs had stuck with gcc 4.2.1, before the move to GPLv3. I
> think there are two options, apply your patch above, or add a check to
> ./make.bash to fail the build if that version of gcc is the default.
> The first is probably the easiest
>
NetBSD base system just uses GCC 4.5.4 and GDB 7.3.1, :-)
it's clearly marked as licensed under gplv3 in the repository, so why
resist it?

>
> Do you think there is value in creating a small test program, perhaps
> in misc, that is compiled by dist that checks a few things like this.
> We have a similar check inside the runtime that does sanity checks for
> gc.
>
I will try to push the fixes upstream first. the gcc one seems simple enough
to be accepted. the kernel VFP one is more subtle.

>
> You mentioned you had access to a newer kernel image than the one
> available on the RPi website which resolved the sd card issues, can
> you show me where to get that kernel ?
>
I just compiled the latest kernel from source, compiling them is simple
on Unixes (I build them on Linux):
1. get the source (i used git://github.com/jsonn/src.git)
2. cd src
3. ./build.sh -m evbarm tools # this compiles the cross compiling tools
4. ./build.sh -m evbarm -u kernel=RPI # build the default kernel for RPi
5. copy sys/arch/evbarm/compile/obj/RPI/kernel.img to the boot paritition

I didn't rebuild the whole userland and just used the 20130124 snapshot
image.
PS: If you don't want to build the kernel from source (it won't take long),
i can provide a copy of mine.

[dave_cheney.net, 2013-02-03 22:55:26]

> I'm just amazed by the fact that enabling cgo together with GOARM=6 can
> crash
> the kernel.
> However, one can enable either one of those two features (but not both)
> without
> any trouble.

I have the same problem with freebsd/arm. The VFP detection code used
to crash the kernel, but they fixed that, now a vfp detection passes,
but a vfp enabled go binary will crash the kernel, hence GOARM=5. Best
I can make out the kernel mode is not saving the VFP registers
properly. As an observation, not may folks are supporting VFP2.

> i have a ugly hack (workarounds) for all these problems in cmd/dist here:
> https://codereview.appspot.com/7286044/
> but I will try to contact NetBSD team to fix the two bugs before mailing
> that
> bag of ugly hacks.

If you can get the fix into NetBSD then that would be preferable to
-O1 in my mind. Maybe a middle ground for cmd/dist is to use an #ifdef
to hard code GOARM=5 for freebsd and netbsd?

> NetBSD base system just uses GCC 4.5.4 and GDB 7.3.1, :-)
> it's clearly marked as licensed under gplv3 in the repository, so why resist
> it?

Interesting, gdb 7.x is available in freebsd ports. but there is no
arm support, does the NetBSD gdb 7.3.1 support arm ?

> I will try to push the fixes upstream first. the gcc one seems simple enough
> to be accepted. the kernel VFP one is more subtle.

Fair enough, it is a lot of work, and only really useful during porting.

> I just compiled the latest kernel from source, compiling them is simple
> on Unixes (I build them on Linux):
> 1. get the source (i used git://github.com/jsonn/src.git)
> 2. cd src
> 3. ./build.sh -m evbarm tools # this compiles the cross compiling tools
> 4. ./build.sh -m evbarm -u kernel=RPI # build the default kernel for RPi
> 5. copy sys/arch/evbarm/compile/obj/RPI/kernel.img to the boot paritition

That is pretty neat, I'll give it a go.

[minux1, 2013-07-23 19:34:24]

R=close