This is the mail archive of the
mailing list for the GCC project.
Re: gccgo - illegal instruction on ia64
- From: Ian Lance Taylor <iant at golang dot org>
- To: Manner Róbert <rmanni at gmail dot com>
- Cc: gcc-help <gcc-help at gcc dot gnu dot org>
- Date: Tue, 29 Jan 2019 06:30:26 -0800
- Subject: Re: gccgo - illegal instruction on ia64
- References: <email@example.com>
On Tue, Jan 29, 2019 at 2:11 AM Manner Róbert <firstname.lastname@example.org> wrote:
> I am having some issues with gccgo on ia64 (Itanium architecture).
> I have compiled gcc (8.2.0) with only configure options:
> (Also tried adding --with-libffi, but did not change the behaviour.)
> The resulting gccgo seems to compile a hello world successfully and the
> program seems to run fine:
> > gccgo -o hello hello.go
> > ./hello
> However, the "go" binary which gets created, seems to have problems. In sum:
> - for "go build" I get SIGILL
> - for "go --help" I get "fatal error: libgo built without FFI does not
> support reflect.Call or runtime.SetFinalizer"
> No matter what I try, somehow libffi does not get used. Doing the same
> compile on amd64 works fine.
> I am less worried about having no reflection support than the SIGILL
> which seems to suggest gccgo might not produce good binary for ia64.
> Have you seen similar / do you have any idea? Is anyone using ia64
> successfully? Can it be a problem if the kernel(and its headers) I am
> compiling on is quite old?
> All produced binaries (go, lib*so*) are ia64 at least according to the
> "file" utility.
> Example backtrace of a go build:
> > CGO_ENABLED=0 GOTRACEBACK=system go build -a
> SIGILL: illegal instruction
> PC=2305843009225255986 m=2 sigcode=128
What is the instruction at that PC? Is it valid? The backtrace
suggests that the problem is occurring in C code, which is of course
not compiled with gccgo as such. It may be from the C library, or it
may be compiled with gcc.
To get libffi support you will need to add support for
FFI_GO_CLOSURES, which means writing the functions ffi_prep_go_closure
and ffi_call_go. On most platforms this is not too hard; you
basically have to pass the closure argument to ffi_call_go in the
static chain register. I'm not familiar with how ia64 handles the
static chain, though.