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@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev