This is the mail archive of the gcc-help@gcc.gnu.org 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] |
On 1/29/19 3:30 PM, Ian Lance Taylor wrote: > On Tue, Jan 29, 2019 at 2:11 AM Manner Róbert <rmanni@gmail.com> 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 libgo.so 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 that. 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! Robert > > 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] |