[aarch64-port-dev ] Issue with turning off UseOnStackReplacement with TieredCompilation

Edward Nevill edward.nevill at linaro.org
Tue Feb 11 08:12:00 PST 2014


On Tue, 2014-02-11 at 09:49 -0500, Andy Johnson wrote:
> (gdb) x/20i $pc-40
>    0x7fa1098c50:    add    x0, x0, #0x8
>    0x7fa1098c54:    str    x0, [x1,#112]
>    0x7fa1098c58:    ands    x0, x0, #0x1ff8
>    0x7fa1098c5c:    b.eq    0x7fa1098c5c
>    0x7fa1098c60:    b    0x7fa1098c7c
>    0x7fa1098c64:    ldr    x8, [x12,#32]
>    0x7fa1098c68:    ldr    x0, [x8,#12]
>    0x7fa1098c6c:    add    x0, x0, #0x8
>    0x7fa1098c70:    str    x0, [x8,#12]
>    0x7fa1098c74:    ands    x0, x0, #0x1ff8
> => 0x7fa1098c78:    b.eq    0x7fa1098c78

Andy,

I think you will find the above instruction to be the source of the problem.

Now you need to find what generated this instruction.

Run the program to this point again. Then set watchpoint on the location

IE.

wa *0x7fa1098c78

Then run the program again, no need to specify the args again, just the run command on its own.

run

The watchpoint will trigger a couple of times (in memset). Each time it triggers disassemble the location to see has it written the above instruction

so

x/i 0x7fa1098c5c

When you see the instruction having just been written use the 'up' command to step back up the stack to find out what piece of code is generating this.

Regards,
Ed.

>    0x7fa1098c7c:    ldrb    w8, [x22]
>    0x7fa1098c80:    add    w9, w8, #0x800
>    0x7fa1098c84:    ldr    x9, [x21,w9,uxtw #3]
>    0x7fa1098c88:    br    x9
>    0x7fa1098c8c:    str    x22, [x29,#-56]
>    0x7fa1098c90:    ldr    x8, [x29,#-16]
>    0x7fa1098c94:    cbz    x8, 0x7fa1098d08
>    0x7fa1098c98:    stp    x30, xzr, [sp,#-16]!
>    0x7fa1098c9c:    stp    x28, x29, [sp,#-16]!
> 
> 
> BTW, it also hangs when run under the slowdebug simulator.  This is
> thread 2:
> (gdb) thread 2
> [Switching to thread 2 (Thread 0x7ffff563d700 (LWP 15035))]
> #0  0x00007ffff5b69cb1 in CPUState::updatePC (this=0x7ffff001c510)
>     at cpustate.cpp:67
> 67      trace_buffer[trace_counter++ % trace_size] = pc;
> (gdb) where
> #0  0x00007ffff5b69cb1 in CPUState::updatePC (this=0x7ffff001c510)
>     at cpustate.cpp:67
> #1  0x00007ffff5b87dae in AArch64Simulator::run (this=0x7ffff001c510)
>     at simulator.cpp:344
> #2  0x00007ffff62827fa in setup_arm_sim (sp=0x7ffff563b320,
> calltype=8)
> 
> at /home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/aarch64_call.cpp:173
> #3  0x00007ffff62829ec in aarch64_prolog ()
> 
> at /home/andyj/openjdk-8/jdk8-111/hotspot/src/cpu/aarch64/vm/aarch64_linkage.S:112
> #4  0x00007ffff6760932 in JavaCalls::call_helper
> (result=0x7ffff563b940, 
>     m=0x7ffff563b820, args=0x7ffff563b6e0,
> __the_thread__=0x7ffff000c4e8)
> 
> at /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/runtime/javaCalls.cpp:406
> #5  0x00007ffff69bd31c in os::os_exception_wrapper (
>     f=0x7ffff67602a2 <JavaCalls::call_helper(JavaValue*,
> methodHandle*, JavaCallArguments*, Thread*)>, value=0x7ffff563b940,
> method=0x7ffff563b820, 
>     args=0x7ffff563b6e0, thread=0x7ffff000c4e8)
> 
> at /home/andyj/openjdk-8/jdk8-111/hotspot/src/os/linux/vm/os_linux.cpp:5119
> #6  0x00007ffff67602a0 in JavaCalls::call (result=0x7ffff563b940,
> method=..., 
>     args=0x7ffff563b6e0, __the_thread__=0x7ffff000c4e8)
> 
> at /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/runtime/javaCalls.cpp:307
> ---Type <return> to continue, or q <return> to quit---
> #7  0x00007ffff6774614 in jni_invoke_nonstatic (env=0x7ffff000c6f8, 
>     result=0x7ffff563b940, receiver=0x7ffff00fd4a0,
> call_type=JNI_NONVIRTUAL, 
>     method_id=0x7ffff010fee8, args=0x7ffff563b8f0, 
>     __the_thread__=0x7ffff000c4e8)
> 
> at /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/prims/jni.cpp:1383
> #8  0x00007ffff6775573 in jni_NewObject (env=0x7ffff000c6f8, 
>     clazz=0x7ffff00ea088, methodID=0x7ffff010fee8)
> 
> at /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/prims/jni.cpp:1500
> #9  0x00007ffff4e1103a in JNU_NewStringPlatform (env=0x7ffff000c6f8, 
>     str=0x7ffff0001ad8
> "/home/andyj/openjdk-8/jdk8-111/build/linux-aarch64-normal-server-slowdebug/images/j2sdk-image/jre")
> 
> at /home/andyj/openjdk-8/jdk8-111/jdk/src/share/native/common/jni_util.c:741
> #10 0x00007ffff4e10e8d in NewStringPlatform (env=0x7ffff000c6f8, 
>     str=0x7ffff0001ad8
> "/home/andyj/openjdk-8/jdk8-111/build/linux-aarch64-normal-server-slowdebug/images/j2sdk-image/jre")
> 
> at /home/andyj/openjdk-8/jdk8-111/jdk/src/share/native/common/jni_util.c:711
> #11 0x00007ffff6761ee5 in
> java_lang_String::create_from_platform_dependent_str
>     (
>     str=0x7ffff0001ad8
> "/home/andyj/openjdk-8/jdk8-111/build/linux-aarch64-normal-server-slowdebug/images/j2sdk-image/jre", __the_thread__=0x7ffff000c4e8)
> 
> at /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/classfile/javaClasses---Type <return> to continue, or q <return> to quit---
> .cpp:245
> #12 0x00007ffff67c8462 in set_property (props=..., 
>     key=0x7ffff0001728 "java.home", 
>     value=0x7ffff0001ad8
> "/home/andyj/openjdk-8/jdk8-111/build/linux-aarch64-normal-server-slowdebug/images/j2sdk-image/jre", __the_thread__=0x7ffff000c4e8)
> 
> at /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/prims/jvm.cpp:319
> #13 0x00007ffff67c8768 in JVM_InitProperties (env=0x7ffff000c6f8, 
>     properties=0x7ffff563c4e8)
> 
> at /home/andyj/openjdk-8/jdk8-111/hotspot/src/share/vm/prims/jvm.cpp:343
> #14 0x00007ffff4e0846f in Java_java_lang_System_initProperties (
>     env=0x7ffff000c6f8, cla=0x7ffff563c4d8, props=0x7ffff563c4e8)
> 
> at /home/andyj/openjdk-8/jdk8-111/jdk/src/share/native/java/lang/System.c:379
> #15 0x00007ffff5b8f0c7 in gload0L () at linkage.s:265
> #16 0x00007fffe1081e7c in ?? ()
> #17 0x0000000000000000 in ?? ()
> 
> 
> 
> 
> On 11 February 2014 09:41, Edward Nevill <edward.nevill at linaro.org>
> wrote:
>         Hi Andy,
>         
>         
>         On Tue, 2014-02-11 at 09:34 -0500, Andy Johnson wrote:
>         > #0  0x0000007fa1098c78 in ?? ()
>         > (gdb) where
>         > #0  0x0000007fa1098c78 in ?? ()
>         > #1  0x0000000000000034 in ?? ()
>         > #2  0x0000000000000034 in ?? ()
>         > Backtrace stopped: previous frame identical to this frame
>         (corrupt stack?)
>         
>         
>         Could you disassemble a few instructions around
>         0x0000007fa1098c78 and let us know what you see.
>         
>         Try say
>         
>         x/20i $pc-40
>         
>         Regards,
>         Ed.
>         
>         
> 
> 




More information about the aarch64-port-dev mailing list