qemu-arm and Go

[Nick Craig-Wood]

Can anyone give me a hint on how to make qemu-arm work with Go?

All I'm getting is this

$ qemu-arm test
fatal error: rt_sigaction failure

goroutine 1 [runnable]:

Same thing with qemu 1.4.0 and the latest release 1.5.1

I know it has worked at some point - am I missing something?

Thanks

Nick
--
Nick Craig-Wood <ni...@craig-wood.com> -- http://www.craig-wood.com/nick

[Jan Mercl]

On Thu, Jul 18, 2013 at 6:35 PM, Nick Craig-Wood <ni...@craig-wood.com> wrote:
> Can anyone give me a hint on how to make qemu-arm work with Go?
>
> All I'm getting is this
>
> $ qemu-arm test
> fatal error: rt_sigaction failure
>
> goroutine 1 [runnable]:
>
> Same thing with qemu 1.4.0 and the latest release 1.5.1
>
> I know it has worked at some point - am I missing something?

Before buying a Chromebook we (at work) were using qemu-arm (on Ubuntu
12.04 x68_64) routinely with no problems above eg. longer required
time to build the Go toolchain from sources. I'll check what version
of qemu-arm I have at work tomorrow and report back. BTW: I'm almost
sure I was using Go 1.1.1 release version.

-j

[zeebo]

So I ran into this recently as well and traced it down to the go runtime setting up signal handlers for every signal [1,64] but qemu returns an error for signal handler 64 (at least). I was able to get a large set of stuff working by modifying the runtime to check if it can register for a signal (by passing nils for the other args, the kernel returns if registering for that signal is a guaranteed error) and skipping the ones that it told me wouldn't work.

At that point I stopped using qemu and moved on. Hope that helps!

[Nick Craig-Wood]

On 18/07/13 18:36, zeebo wrote:
> So I ran into this recently as well and traced it down to the go runtime
> setting up signal handlers for every signal [1,64] but qemu returns an
> error for signal handler 64 (at least). I was able to get a large set of
> stuff working by modifying the runtime to check if it can register for a
> signal (by passing nils for the other args, the kernel returns if
> registering for that signal is a guaranteed error) and skipping the ones
> that it told me wouldn't work.

Ah nice one!

I'll have a go with that.

Thanks

[Nick Craig-Wood]

On 18/07/13 19:03, Nick Craig-Wood wrote:
> On 18/07/13 18:36, zeebo wrote:
>> So I ran into this recently as well and traced it down to the go runtime
>> setting up signal handlers for every signal [1,64] but qemu returns an
>> error for signal handler 64 (at least). I was able to get a large set of
>> stuff working by modifying the runtime to check if it can register for a
>> signal (by passing nils for the other args, the kernel returns if
>> registering for that signal is a guaranteed error) and skipping the ones
>> that it told me wouldn't work.
>
> Ah nice one!
>
> I'll have a go with that.
>
> Thanks
>

This seems to fix it. I guess that might be a bug in qemu or the go
runtime - I don't know!

diff -r a7bd9a33067b src/pkg/runtime/os_linux.h
--- a/src/pkg/runtime/os_linux.h Thu Jun 13 12:49:43 2013 +1000
+++ b/src/pkg/runtime/os_linux.h Thu Jul 18 19:24:27 2013 +0100
@@ -16,7 +16,7 @@
void runtime�setitimer(int32, Itimerval*, Itimerval*);


-#define NSIG 65
+#define NSIG 64
#define SI_USER 0

// It's hard to tease out exactly how big a Sigset is, but

[minux]

On Friday, July 19, 2013, Nick Craig-Wood wrote:

On 18/07/13 19:03, Nick Craig-Wood wrote:
> On 18/07/13 18:36, zeebo wrote:
>> So I ran into this recently as well and traced it down to the go runtime
>> setting up signal handlers for every signal [1,64] but qemu returns an
>> error for signal handler 64 (at least). I was able to get a large set of
>> stuff working by modifying the runtime to check if it can register for a
>> signal (by passing nils for the other args, the kernel returns if
>> registering for that signal is a guaranteed error) and skipping the ones
>> that it told me wouldn't work.
>
> Ah nice one!
>
> I'll have a go with that.
>
> Thanks
>

This seems to fix it.  I guess that might be a bug in qemu or the go
runtime - I don't know!

diff -r a7bd9a33067b src/pkg/runtime/os_linux.h
--- a/src/pkg/runtime/os_linux.h        Thu Jun 13 12:49:43 2013 +1000
+++ b/src/pkg/runtime/os_linux.h        Thu Jul 18 19:24:27 2013 +0100
@@ -16,7 +16,7 @@

 void runtime新etitimer(int32, Itimerval*, Itimerval*);

-#define        NSIG    65
+#define        NSIG    64
 #define        SI_USER 0

 // It's hard to tease out exactly how big a Sigset is, but

the original code is correct, as SIGRTMAX is 64 on linux.

qemu is buggy here. 

[zeebo]

Yeah NSIG is supposed to be 1+ the maximum signal so the define is fine. I

believe qemu is using that signal for some internal purpose and doesn't allow

apps it is running to register for it.

I have no idea what signals the go runtime actually uses so it's a scary game

to play.

On Thursday, July 18, 2013 12:26:04 PM UTC-6, Nick Craig-Wood wrote:

On 18/07/13 19:03, Nick Craig-Wood wrote:
> On 18/07/13 18:36, zeebo wrote:
>> So I ran into this recently as well and traced it down to the go runtime
>> setting up signal handlers for every signal [1,64] but qemu returns an
>> error for signal handler 64 (at least). I was able to get a large set of
>> stuff working by modifying the runtime to check if it can register for a
>> signal (by passing nils for the other args, the kernel returns if
>> registering for that signal is a guaranteed error) and skipping the ones
>> that it told me wouldn't work.
>
> Ah nice one!
>
> I'll have a go with that.
>
> Thanks
>

This seems to fix it.  I guess that might be a bug in qemu or the go
runtime - I don't know!

diff -r a7bd9a33067b src/pkg/runtime/os_linux.h
--- a/src/pkg/runtime/os_linux.h        Thu Jun 13 12:49:43 2013 +1000
+++ b/src/pkg/runtime/os_linux.h        Thu Jul 18 19:24:27 2013 +0100
@@ -16,7 +16,7 @@

 void runtime�setitimer(int32, Itimerval*, Itimerval*);

[minux]

Jan, i'm sure you are talking about qemu-system-arm, which simulates a

whole arm machine in full.

and nick is talking about qemu user emulation, where you can run linux/arm

binaries directly on your linux host, e.g. qemu only simulates arm instructions

and translates syscalls into host linux syscalls. it will be faster than whole system

simulation. and i think the arm port was developed using qemu user emulation.

[Jan Mercl]

On Thu, Jul 18, 2013 at 8:59 PM, minux <minu...@gmail.com> wrote:
> Jan, i'm sure you are talking about qemu-system-arm, which simulates a
> whole arm machine in full.

You're correct ;-)

> and nick is talking about qemu user emulation, where you can run linux/arm
> binaries directly on your linux host, e.g. qemu only simulates arm
> instructions
> and translates syscalls into host linux syscalls. it will be faster than
> whole system
> simulation. and i think the arm port was developed using qemu user
> emulation.

This is very interesting and I've never heard about it before!

-j

[minux]

On Friday, July 19, 2013, zeebo wrote:

Yeah NSIG is supposed to be 1+ the maximum signal so the define is fine. I

believe qemu is using that signal for some internal purpose and doesn't allow

apps it is running to register for it.

I have no idea what signals the go runtime actually uses so it's a scary game

to play.

Go doesn't need those signals, but they are caught by default so that

the user program can use os/signal to get notified by them and the runtime

can output stack trace for a deadly signal.

I remembered that SIGRTMAX is used by some thread implementations

internally, so perhaps go runtime should not catch them by default.

e.g. treat it like SIGTSTP.

if it is the case, i will propose a CL. 

[Dave Cheney]

A qemu bug would not be unheard of.

On 19/07/2013, at 4:26, Nick Craig-Wood <ni...@craig-wood.com> wrote:

> On 18/07/13 19:03, Nick Craig-Wood wrote:
>> On 18/07/13 18:36, zeebo wrote:
>>> So I ran into this recently as well and traced it down to the go runtime
>>> setting up signal handlers for every signal [1,64] but qemu returns an
>>> error for signal handler 64 (at least). I was able to get a large set of
>>> stuff working by modifying the runtime to check if it can register for a
>>> signal (by passing nils for the other args, the kernel returns if
>>> registering for that signal is a guaranteed error) and skipping the ones
>>> that it told me wouldn't work.
>>
>> Ah nice one!
>>
>> I'll have a go with that.
>>
>> Thanks
>>
>
> This seems to fix it. I guess that might be a bug in qemu or the go
> runtime - I don't know!
>
> diff -r a7bd9a33067b src/pkg/runtime/os_linux.h
> --- a/src/pkg/runtime/os_linux.h Thu Jun 13 12:49:43 2013 +1000
> +++ b/src/pkg/runtime/os_linux.h Thu Jul 18 19:24:27 2013 +0100
> @@ -16,7 +16,7 @@

> void runtime新etitimer(int32, Itimerval*, Itimerval*);

>
>
> -#define NSIG 65
> +#define NSIG 64
> #define SI_USER 0
>
> // It's hard to tease out exactly how big a Sigset is, but
>
>
>
> --
> Nick Craig-Wood <ni...@craig-wood.com> -- http://www.craig-wood.com/nick
>

> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>