Illegal Instruction in debug_build (original) (raw)

Michael Barker mikeb01 at gmail.com
Thu Nov 24 01:00:48 PST 2011

Hi,

Yes I'm compiling mlvm which is a set of patches on the hotspot tree. I noticed that fix has recently made it's way through to the hotspot branch. However, I'm compiling against gcc 4.2 therefore the compiler falls through to the default case on the ifdef and hits the illegal instruction bug. The fix I'm using locally looks like:

address os::current_stack_pointer() { #if defined(SPARC_WORKS) register void esp; asm("mov %%"SPELL_REG_SP", %0":"=r"(esp)); return (address) ((char)esp + sizeof(long)*2); #else register void *esp; asm("mov %%"SPELL_REG_SP", %0":"=r"(esp)); return (address) esp; #endif }

And similar for "_get_previous_fp()" in os_bsd_x86.cpp. I'm not sure what the correct fix is here. Should I be using clang instead of gcc 4.2 or should there be an additional option on the #ifdef, e.g. if defined(clang) || defined(llvm) || defined(gcc42)?

Mike.

On Thu, Nov 24, 2011 at 6:36 AM, Alexander Strange <astrange at apple.com> wrote:

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

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