Debugframesize

[adinn]

This PR fixes issue #2624. The changes in the compiler code ensure that a Frame.returned() callback occurs at the end of any basic block that also includes a call to Frame.leave(). This is needed to ensure that marks inserted by the Substrate implementors of Frame are correctly located. Substrate Frame.leave implementations still add marks for EPILOGUE_START and EPILOGUE_INCD_RSP. Generation of EPILOGUE_END occurs in Substrate Frame.returned implementations i.e. at the end of the basic block terminated by the return (or, in certain cases, a method exiting jump to a handler). The current code places the EPILOGUE_END mark before the terminating return (or jump). In deed, in some cases it also precedes safepoint code or other code that operates with the empty frame.

The result of making this compiler change is to allow the debug info frame record generator to decrement the stack frame size at EPILOGUE_INCD_RSP but then restore it again at EPILOGUE_END if it finds there is code that follows the EPILOGUE_END.

[adinn]

@olpaw @tkrodriguez Any chance of a review for this small patch?

[tkrodriguez]

It looks ok to me. I'll run it through our internal gates today.

[adinn]

Thanks Tom!

[olpaw]

@adinn thanks for the fix. Unfortunately this breaks debug_frame generation of EE debuginfo. I haved to fix that first & then I can merge your PR. Sorry for the inconvenience.

[adinn]

@olpaw No problem. Thanks for letting me know. I hope the compiler changes offer a better/simpler approach for the EE code to generate frame info.

[olpaw]

Merged on master: 7b174f1

BTW, the test that failed and made me aware that I need to adjust EE debuginfo is a good one. You might want to add something similar on CE. It builds a simple image (that has methods with multiple exit points) and then runs that image with GDB in "assembly single stepping mode" (si) until it reaches the breakpoint for exit@plt / exit. After each si it dumps the stack with bt and searches for in ?? in the stacktrace. If it finds such a string the test fails (because it found a code location where getting a stack trace does not work).

[adinn]

BTW, the test that failed and made me aware that I need to adjust EE debuginfo is a good one. You might want to add something similar on CE. It builds a simple image (that has methods with multiple exit points) and then runs that image with GDB in "assembly single stepping mode" (si) until it reaches the breakpoint for exit@plt / exit. After each si it dumps the stack with bt and searches for in ?? in the stacktrace. If it finds such a string the test fails (because it found a code location where getting a stack trace does not work).

Hmm, that's a very good idea! I'll develop a test along those lines.