Hi Jini, On 02/02/2019 02:16, Jini George wrote: > Do we reach here after AARCH64CurrentFrameGuess.run() fails to get the > PC ?
Yes, that's right. It's the else branch (not interpreter and not compiler) that sets this.pc to null. > If so, was wondering if it would make more sense to scan from the > top of stack sp obtained from > context.getRegisterAsAddress(AARCH64ThreadContext.SP) to the sp of the > last known java frame with thread.getLastJavaSP() in > AARCH64CurrentFrameGuess.run() -- otherwise was wondering if we are > risking an exception by running off the top of the stack while scanning > in the upward direction (towards lower addresses) for > CALLEE_FRAME_SEARCH_LIMIT * addressSize from the previous Java SP > (though the scan range is small). > I think this is much better, thanks. But we still have the problem that the two-argument AARCH64Frame constructor is wrong: I don't think it's ever correct to assume the PC is at SP[-1]. And so we need to fix the other uses of it. I've made another patch that moves the frame scanning into LinuxAARCH64JavaThreadPDAccess.java, searching between the last-known Java SP and and current thread SP as described above. And we now use this to find a PC any time we would have called the two argument constructor before. http://cr.openjdk.java.net/~ngasson/8209413/webrev.02/ Please let me know what you think. + Assert.that(jcw.getLastJavaPC() != null, "last Java pc should be set"); I believe this is OK because the last Java SP/FP/PC are set by MacroAssembler::set_last_Java_frame, and I can't see any case where it would set SP and FP but not PC. Thanks, Nick
