Getting a Go executable(hugo) to run Intel Galileo/Quark

[David Markey]

I'm trying to get hugo to work on my Alpine distro that's running on my Intel gallileo(Quark CPU).

I've overcome a few hurdles already.

This CPU Doesn't have MMX so gcc-go was needed to compile hugo into a binary (in a virtual machine)

But after copying the hugo binary to the galileo Hugo doesn't work. I get the following error:

fatal error: unexpected signal during runtime execution [signal SIGSEGV: segmentation violation code=0x1 addr=0x44 pc=0xb7658e62] goroutine 1 [running]: runtime.dopanic_m :0 runtime.throw :0 runtime.sigpanic :0 runtime.sigtrampgo :0 runtime.sigtramp :0 :0 goroutine 4 [select]: go.x2eopencensus.x2eio..z2fstats..z2fview.worker.start /root/go/pkg/mod/go.openc...@v0.22.0/stats/view/worker.go:154 created by go.x2eopencensus.x2eio..z2fstats..z2fview.go.x2eopencensus.x2eio..z2fstats..z2fview..init0 /root/go/pkg/mod/go.openc...@v0.22.0/stats/view/worker.go:32 +0x17a

This could be:

1. Galileo has 256MB of ram only, The executable is 127MB, perhaps there simply isn't enough memory?
2. Quark has a well known bug. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575%22 that means it mishandles LOCK instructions and causes a segfault.

On a normal C toolchain, the assembler can strip the LOCK operation using "-Xassembler '-momit-lock-prefix=yes'" CFLAG (Galileo is single core so it's not needed)

However I'm not sure what the equivalent would be on a go build toolchain, perhaps it's simply not possible?

The compiled binary works perfectly in the virtual machine.

[Ian Lance Taylor]

On Thu, Apr 15, 2021 at 1:11 PM David Markey <ad...@dmarkey.com> wrote:
>
> I'm trying to get hugo to work on my Alpine distro that's running on my Intel gallileo(Quark CPU).
>
> I've overcome a few hurdles already.
>
> This CPU Doesn't have MMX so gcc-go was needed to compile hugo into a binary (in a virtual machine)
>
> But after copying the hugo binary to the galileo Hugo doesn't work. I get the following error:
>
> fatal error: unexpected signal during runtime execution [signal SIGSEGV: segmentation violation code=0x1 addr=0x44 pc=0xb7658e62] goroutine 1 [running]: runtime.dopanic_m :0 runtime.throw :0 runtime.sigpanic :0 runtime.sigtrampgo :0 runtime.sigtramp :0 :0 goroutine 4 [select]: go.x2eopencensus.x2eio..z2fstats..z2fview.worker.start /root/go/pkg/mod/go.openc...@v0.22.0/stats/view/worker.go:154 created by go.x2eopencensus.x2eio..z2fstats..z2fview.go.x2eopencensus.x2eio..z2fstats..z2fview..init0 /root/go/pkg/mod/go.openc...@v0.22.0/stats/view/worker.go:32 +0x17a
>
> This could be:
>
> Galileo has 256MB of ram only, The executable is 127MB, perhaps there simply isn't enough memory?

This particular error looks like a nil dereference. That would only
be caused by insufficient memory if the Go code calls C code that
calls malloc and doesn't check for a return value of NULL.

> Quark has a well known bug. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575%22 that means it mishandles LOCK instructions and causes a segfault.
>
> On a normal C toolchain, the assembler can strip the LOCK operation using "-Xassembler '-momit-lock-prefix=yes'" CFLAG (Galileo is single core so it's not needed)
>
> However I'm not sure what the equivalent would be on a go build toolchain, perhaps it's simply not possible?

Since you are using gccgo, the same option should work. But you might
possibly have to recompile the Go library with that option.

Ian

[David Markey]

Thanks for the reply!

After recompiling gcc-go and libgo with the " -Wa,-momit-lock-prefix=yes -march=i586" flags and compiling hugo with:

go build  -gccgoflags="-Wa,-momit-lock-prefix=yes -march=i586"

Still getting an error, but a more terse version:

./hugo
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xc pc=0xb768bdf2]

goroutine 1 [running]:

The same executable still works on my VM (although blows up with more than 1 core on the VM, as one might expect)

Any more pointers? This is just a play project, if it doesn't work it's not the end of the world.

[Brian Candler]

Can you add a swapfile?  That could rule out low RAM as the problem, even if it's very inefficient.

Aside: 127MB does sound like a very large binary, compared to what the standard go toolchain produces.   The official hugo amd64 binary is about 44MB:

$ tar -tvzf hugo_0.82.0_Linux-64bit.tar.gz

-rw-r--r--  0 root   root    11357 21 Mar 17:17 LICENSE

-rw-r--r--  0 root   root    12345 21 Mar 17:17 README.md

-rwxr-xr-x  0 root   root 44568576 21 Mar 17:51 hugo

And k3s (a complete kubernetes distribution) is around 55MB.

Given the limited target system, maybe tinygo is worth playing with - although I have no idea whether hugo will work with the subset of language features it provides.

[David Markey]

galileo:/home/galileo# free

              total        used        free      shared  buff/cache   available

Mem:         209592       20612       34620          76      154360      180376

Swap:       1048572           0     1048572

galileo:/home/galileo# ./hugo

panic: runtime error: invalid memory address or nil pointer dereference

[signal SIGSEGV: segmentation violation code=0x1 addr=0xc pc=0xb76f5df2]

goroutine 1 [running]:

galileo:/home/galileo# ldd ./hugo 

/lib/ld-musl-i386.so.1 (0xb7f1a000)

libgo.so.16 => /usr/lib/libgo.so.16 (0xb3a9e000)

libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb3a80000)

libc.musl-x86.so.1 => /lib/ld-musl-i386.so.1 (0xb7f1a000)

libucontext.so.1 => /lib/libucontext.so.1 (0xb3a7b000)

galileo:/home/galileo# file ./hugo

./hugo: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-i386.so.1, with debug_info, not stripped

Good suggestion, alas no breakthrough. Will investigate tinygo, This one "feels" close..though, spends 12 seconds doing *something* - although on a CPU this slow it might actually just be loading the binary into memory.

galileo:/home/galileo# time ./hugo

panic: runtime error: invalid memory address or nil pointer dereference

[signal SIGSEGV: segmentation violation code=0x1 addr=0xc pc=0xb7700df2]

goroutine 1 [running]:

Command exited with non-zero status 2

real 0m 12.62s

user 0m 11.52s

sys 0m 0.99s

 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/475a30e7-8404-4af4-8ae2-3aff0dcc6a0en%40googlegroups.com.