Illegal Instruction in debug_build (original) (raw)

Alexander Strange astrange at apple.com
Wed Nov 23 22:36:21 PST 2011

I assume this thread is discussing building something besides macosx-port on OS X.

I fixed this in the debug build in macosx-port hotspot here: http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/51d10977410a

Your code seems to be failing because of a compiler bug. That said, the LLVM developers recommend against the use of register variables.

On Oct 15, 2011, at 7:23 PM, John Rose wrote:

I don't know the ins and outs of asm and grabbing rsp on Mac, but the OS X port group probably know something about it. -- John

On Oct 15, 2011, at 8:49 AM, Michael Barker wrote:

Good luck! Thanks. I found where the problem is, it's in the os::currentstackpointer method in osbsdx86.cpp and it depends on level of compilation. If I compile the code below without optimisation e.g.: #include <stdio.h> class os { public: void* currentstackpointer(); }; void* os::currentstackpointer() { register void *esp asm ("rsp"); return esp; } int main() { os o = os(); printf("%p\n", o.currentstackpointer()); } # g++ test.cc -o test It will generate the following assembly: _ZN2os21currentstackpointerEv: 0000000000000000 pushq %rbp 0000000000000001 movq %rsp,%rbp 0000000000000004 movq %rdi,0xf8(%rbp) 0000000000000008 movq 0xe0(%rbp),%rax 000000000000000c movq %rax,%rsp 000000000000000f movq %rsp,%rax 0000000000000012 movq %rax,0xe8(%rbp) 0000000000000016 movq 0xe8(%rbp),%rax 000000000000001a movq %rax,0xf0(%rbp) 000000000000001e movq 0xf0(%rbp),%rax 0000000000000022 popq %rbp And will fail with an illegal instruction. If optimisation is added (-O1 is sufficient) it works fine: # g++ -O1 test.cc -o test And the generated assembly looks far more sane: 0000000000000000 pushq %rbp 0000000000000001 movq %rsp,%rbp 0000000000000004 movq %rsp,%rax 0000000000000007 popq %rbp 0000000000000008 ret So I've added -01 to the debug flags in hotspot/make/bsd/makefiles/gcc.make and it now seems to run okay. I'm not sure that it's the best fix. Is there are better way to get hold of the stack pointer? I.e. one that doesn't get stomped over by a lack of optimisation :-). Not sure if this specific to Mac OS 7 or gcc 4.2. Mike.

mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

More information about the macosx-port-dev mailing list