Illegal Instruction in debug_build

[Michael Barker]

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::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
>