- Reason of both bugs:
- For the very first frame, Unwinder doesn't check the validity of Full UnwindPlan before creating StackFrame from it:
When 'process launch' command is run after setting a breakpoint in inferior, the Unwinder runs and saves only Frame 0 (the frame in which breakpoint was set) in thread's StackFrameList i.e. m_curr_frames_sp. However, it doesn't check the validity of the Full UnwindPlan for this frame by unwinding 2 more frames further. - Unwinder doesn't update the CFA value of Cursor when Full UnwindPlan fails and FallBack UnwindPlan succeeds in providing valid CFA values for frames:
Sometimes during unwinding of stack frames, the Full UnwindPlan inside the RegisterContextLLDB object may fail to provide valid CFA values for these frames. Then the Fallback UnwindPlan is used to unwind the frames.
If the Fallback UnwindPlan succeeds, then it provides a valid new CFA value. The RegisterContextLLDB::m_cfa field of Cursor object is updated during the Fallback UnwindPlan execution. However, UnwindLLDB misses the implementation to update the 'cfa' field of this Cursor with this valid new CFA value.
- For the very first frame, Unwinder doesn't check the validity of Full UnwindPlan before creating StackFrame from it:
- This patch fixes both these issues.
- Remove XFAIL in test files corresponding to these 2 Bugs
Change-Id: I932ea407545ceee2d628f946ecc61a4806d4cc86
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
I would do this with an assert instead of a conditional check. This method is only called from UnwindLLDB::AddFirstFrame(). AddFirstFrame starts by ensuring that m_frames is empty. It constructs a Cursor object for the first stack frame, pushes it to m_frames. And then it calls UpdateUnwindPlanForFirstFrameIfInvalid().
A conditional makes it look like this is a possible valid arrangement. Instead, what we're checking here is a basic assumption of the state of the object when this method should be called. I think it's an appropriate space to use an assert. If the code were to ever change around this method (or this method was called from another part of the code), we'd need it to crash immediately because the code would no longer be correct.