Debugger: implement architectural unwinding of frameless functions

[jessicah]

Currently compiling the ffmpeg add-on with debug symbols enabled, but in the stack trace, the second to last stack frame seems to be missing unless one uses the step into function.

E.g. I have added a memcpy that's triggering a segfault exception, where the calling function is _MoveAudioFramesToRawDecodedAudioFormatAndUpdateStartTimes(), but this stack frame is not present. Only the function calling _MoveAudio..., _DecodeNextAudioFrame(), is in the call stack.

When I have a breakpoint configured in _DecodeNextAudioFrame, then use Step Into to enter into the _MoveAudioFrames... function, does it then show up in the stack trace. If I use the Run button instead, it doesn't show up in the stack trace either.

[bonefish]

Assuming you don't have debug info for memcpy() this should be the issue: In the absence of debug info Debugger resorts to the fallback method to unwind the current function call -- it uses the return address and previous frame address stored in the current stack frame. Since memcpy() is probably frameless, the stack frame Debugger sees actually stems from the calling function and the values stored in it refer to _DecodeNextAudioFrame(). Thus your second function appears missing.

If you could step out of memcpy(), the function would be back. IIRC advancing to a ret instruction within memcpy() would already help, since Debugger would notice that we're in the function epilogue and only the return address remains on the stack.

In theory it would be possible to deal more intelligently with frameless functions. Debugger could analyze the function to find a code path that leads out of the function and thus determine the return address and the calling function's stack and frame pointer.

So, this is really more like a missing feature than a bug. Unless debug info for memcpy() is available that is.

[anevilyak]

Replying to bonefish:

In theory it would be possible to deal more intelligently with frameless functions. Debugger could analyze the function to find a code path that leads out of the function and thus determine the return address and the calling function's stack and frame pointer.

That's indeed a (long-standing) TODO: ​http://cgit.haiku-os.org/haiku/tree/src/apps/debugger/arch/x86/ArchitectureX86.cpp#n392

This was one of those issues I've been putting off since it somewhat dovetails into handling of code compiled with -fomit-frame-pointer; at least AFAICT, completely handling the latter correctly would also have the side effect of dealing with the frameless case as well, unless I'm missing something. Up until now I haven't really had the time to familiarize myself enough with x86 assembly to actually implement that though.