This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gccgo - illegal instruction on ia64

On 1/29/19 3:30 PM, Ian Lance Taylor wrote:
> On Tue, Jan 29, 2019 at 2:11 AM Manner Róbert <> wrote:
>> I am having some issues with gccgo on ia64 (Itanium architecture).
>> I have compiled gcc (8.2.0) with only configure options:
>> --enable-languages=c,c++,go
>> (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
>> 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.

According to gdb disassembly it is "mov.i ar.pfs=r36". Its inside
function "runtime.mcall" in

I will try to verify if that is true with some disassembler tomorrow,
but I am not yet sure how to do that. Do you? Anyways, I will read about

I have attached the disassembly gdb produces at the SIGILL. The
instruction set on that machine is itanium2 (mckinley) and it gets
detected correctly, at least as long as I can tell. I will also try to
force itanium1 tomorrow and also try with an older version of 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.

I will have a look at it, at least try, though not sure if I am capable :(
Thanks for your quick response!


> Ian

Attachment: gdb-asm.txt
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]