Illegal Instruction in debug_build

[Michael Barker]

This appears to work.  By work, it does crash when compiled in debug mode.

--- a/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp	Sun Oct 16 20:57:02 2011 +0100
+++ b/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp	Sat Oct 22 12:27:35 2011 +0100
@@ -275,12 +275,11 @@
 #endif

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

I'm not sure how correct it is and I'm unsure if we need to add an
offset to get the stack pointer to the correct location.  However it
appears from the use cases that I can find that an exact value for the
stack pointer is not necessary.  AFAICT the JVM only needs to know the
relative location of a memory reference compared to the stack pointer.
 If it is out by a small amount then it should not matter too much?
If the exact location were required then I guess it would be doomed to
failure as by the time we've got the value and used it the stack
pointer could we have moved?

Mike.

On Sun, Oct 16, 2011 at 12:23 AM, John Rose <john.r.rose at oracle.com> 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
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>