This is an archive of the discontinued LLVM Phabricator instance.

Fix to solve Bug 23139 & Bug 23560
ClosedPublic

Authored by abhishek.aggarwal on Nov 2 2015, 5:02 AM.

Details

Summary
  • Reason of both bugs:
    1. 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.
    2. 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.
  • 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>

Diff Detail

Repository
rL LLVM

Event Timeline

abhishek.aggarwal retitled this revision from to Fix to solve Bug 23139 & Bug 23560.
abhishek.aggarwal updated this object.
clayborg resigned from this revision.Nov 2 2015, 11:02 AM
clayborg removed a reviewer: clayborg.

I will defer to Jason Molenda.

jasonmolenda accepted this revision.Nov 11 2015, 9:29 PM
jasonmolenda edited edge metadata.

Hi Abhishek, I apologize for the long delay in reviewing this one, I needed to find a solid 30-45 minute block to review the changes and the current state of the unwinder code before I really understood what is going on here.

I think this change looks good, please commit it when you have a chance.

source/Plugins/Process/Utility/UnwindLLDB.cpp
320 ↗(On Diff #38893)

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.

This revision is now accepted and ready to land.Nov 11 2015, 9:29 PM
abhishek.aggarwal edited edge metadata.

Used Assert instead of If condition

Removed log and inserted statement terminator

Hello Jason

No problem regarding the delay. Thanks a lot for reviewing the patch. I have made the changes as suggested by you. I will land it now.

This revision was automatically updated to reflect the committed changes.