Illegal Instruction in debug_build

[Alexander Strange]

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::current_stack_pointer method in os_bsd_x86.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* current_stack_pointer();
> };
> 
> void* os::current_stack_pointer() {
> register void *esp __asm__ ("rsp");
> return esp;
> }
> 
> int main() {
> os o = os();
> printf("%p\n", o.current_stack_pointer());
> }
> 
> # g++ test.cc -o test
> 
> It will generate the following assembly:
> 
> __ZN2os21current_stack_pointerEv:
> 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
>