<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 2, 2017 at 6:22 AM Alex Bradbury <<a href="mailto:asb@asbradbury.org">asb@asbradbury.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 21 February 2017 at 18:23, Robinson, Paul <<a href="mailto:paul.robinson@sony.com" class="gmail_msg" target="_blank">paul.robinson@sony.com</a>> wrote:<br class="gmail_msg">
<br class="gmail_msg">
> In DWARF, the idea is that if the debugger is doing a "step in" operation<br class="gmail_msg">
> for a call to the function, where is the most reasonable place to stop<br class="gmail_msg">
> execution, that is still "before" the first statement?  Debug info for<br class="gmail_msg">
> parameters and local variables commonly points to stack frame slots, so<br class="gmail_msg">
> generally it's not helpful (for the user) to stop before the stack/frame<br class="gmail_msg">
> pointer is set up the way the debug info expects.<br class="gmail_msg">
><br class="gmail_msg">
> Stashing callee-saved registers is not necessarily part of this, although<br class="gmail_msg">
> if you're using the stack pointer as a frame pointer and doing pushes to<br class="gmail_msg">
> save registers, you need to be done fiddling with SP before you can say<br class="gmail_msg">
> the prologue is ended.<br class="gmail_msg">
> --paulr<br class="gmail_msg">
<br class="gmail_msg">
Thanks. I'm starting to think the better fix might be to add an<br class="gmail_msg">
iterator argument to emitPrologue and emitEpilogue to indicate<br class="gmail_msg">
after/before the callee-saves. Does anyone have particular views on<br class="gmail_msg">
this one way or another?<br class="gmail_msg"><br class="gmail_msg"></blockquote><div><br></div><div>Scheduling can interfere with this as you might schedule or move something before saves on occasion.</div><div><br></div><div>-eric </div></div></div>