<div dir="ltr">Seems like I found an old gem where the issue with the frame pointer was first discovered<br><br><a href="https://bugs.openjdk.org/browse/JDK-8022335">https://bugs.openjdk.org/browse/JDK-8022335</a><div><a href="https://github.com/openjdk/jdk/commit/1c2a7eea85ea261102687190d6b2e92c560770b8">https://github.com/openjdk/jdk/commit/1c2a7eea85ea261102687190d6b2e92c560770b8</a><br><br>best regards,<div>Julian</div></div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 11, 2024 at 4:12 PM Julian Waters <<a href="mailto:tanksherman27@gmail.com">tanksherman27@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Dean,<br>
<br>
Thanks for the quick reply. At the risk of testing your patience, I<br>
don't really follow, since that is how os::get_sender_for_C_frame is<br>
implemented on other platforms (I copied it from Linux x86 in this<br>
case). All I got from the comment is that the only reason we usually<br>
have to use the StackWalk API on Windows is because the frame pointer<br>
is not saved when using the Microsoft compiler, however in my case I'm<br>
not using the Microsoft compiler and have verified that the frame<br>
pointer is saved in my custom JVMs. I'm not sure how<br>
VMError::print_native_stack on other platforms manages to work when<br>
they also do<br>
<br>
return frame(fr->sender_sp(), fr->link(), fr->sender_pc());<br>
<br>
in os::get_sender_for_C_frame like I did here<br>
<br>
Thanks for your time and patience!<br>
<br>
best regards,<br>
Julian<br>
<br>
On Thu, Jul 11, 2024 at 3:17 PM <<a href="mailto:dean.long@oracle.com" target="_blank">dean.long@oracle.com</a>> wrote:<br>
><br>
> Using fr->link() in get_sender_for_C_frame() gives the wrong answer because it refers to the current frame, not the sender frame. There is no frame::sender_fp() because the information we need could be anywhere in the frame or even nowhere in the frame. This is what the comment about StackWalk() API is hinting at. Even debuggers can have trouble giving an accurate stack trace if external debug information is missing and frames do not contain the needed information themselves.<br>
><br>
> dl<br>
><br>
> On 7/10/24 10:52 PM, Julian Waters wrote:<br>
><br>
> Hi Dean,<br>
><br>
> I eventually did find frame::link(), but ultimately it didn't seem to help as VMError::print_native_stack still doesn't work properly on Windows. It seems as though frame::link() calls addr_at on x86, which in turn calls frame::fp(), which returns _fp. I think whatever sets _fp for VMError::print_native_stack is the missing link here, but unfortunately I don't know where it's set<br>
><br>
> The code that I tried on Windows x64 is attached below<br>
><br>
> best regards,<br>
> Julian<br>
><br>
> // VC++ does not save frame pointer on stack in optimized build. It<br>
> // can be turned off by -Oy-. If we really want to walk C frames,<br>
> // we can use the StackWalk() API.<br>
> frame os::get_sender_for_C_frame(frame* fr) {<br>
> #ifdef __GNUC__<br>
>   return frame(fr->sender_sp(), fr->link(), fr->sender_pc());<br>
> #elif defined(_MSC_VER)<br>
>   ShouldNotReachHere();<br>
>   return frame();<br>
> #endif<br>
> }<br>
><br>
> frame os::current_frame() {<br>
> #ifdef __GNUC__<br>
>   frame f(reinterpret_cast<intptr_t*>(os::current_stack_pointer()),<br>
>           reinterpret_cast<intptr_t*>(__builtin_frame_address(1)),<br>
>           CAST_FROM_FN_PTR(address, &os::current_frame));<br>
>   if (os::is_first_C_frame(&f)) {<br>
>     // stack is not walkable<br>
>     return frame();<br>
>   } else {<br>
>     return os::get_sender_for_C_frame(&f);<br>
>   }<br>
> #elif defined(_MSC_VER)<br>
>   return frame();  // cannot walk Windows frames this way.  See os::get_native_stack<br>
>                    // and os::platform_print_native_stack<br>
> #endif<br>
> }<br>
</blockquote></div>