[Lldb-commits] [PATCH] D75975: [lldb] Copy m_behaves_like_zeroth_frame on stack frame update

Anton Kolesov via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Wed Mar 11 00:52:27 PDT 2020


anton.kolesov created this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Field StackFrame::m_behaves_like_zeroth_frame was introduced in commit
[1], however that commit hasn't added a copying of the field to
UpdatePreviousFrameFromCurrentFrame, therefore the value wouldn't change
when updating frames to reflect the current situation.

The particular scenario, where this matters is following. Assume we have
function `main` that invokes function `func1`. We set breakpoint at
`func1` entry and in `main` after the `func1` call, and do not stop at
the `main` entry. Therefore, when debugger stops for the first time,
`func1` is frame#0, while `main` is frame#1, thus
m_behaves_like_zeroth_frame is set to 0 for `main` frame. Execution is
resumed, and stops now in `main`, where it is now frame#0. However while
updating the frame object, m_behaves_like_zeroth_frame remains false.
This field plays an important role when calculating line information for
backtrace: for frame#0, PC is the current line, therefore line
information is retrieved for PC, however for all other frames this is
not the case - calculated PC is a return-PC, i.e. instruction after the
function call line, therefore for those frames LLDB needs to step back
by one instruction. Initial implementation did this strictly for frames
that have index != 0 (and index is updated properly in
`UpdatePreviousFrameFromCurrentFrame`), but m_behaves_like_zeroth_frame
added a capability for middle-of-stack frames to behave in a similar
manner. But because current code now doesn't check frame idx,
m_behaves_like_zeroth_frame must be set to true for frames with 0 index,
not only for frame that behave like one. In the described test case,
after stopping in `main`, LLDB would still consider frame#0 as
non-zeroth, and would subtract instruction from the PC, and would report
previous like as current line.

The error doesn't manifest itself in LLDB interpreter though - it can be
reproduced through LLDB-MI and when using SB API, but not when we
interpreter command "continue" is executed.  Honestly, I didn't fully
understand why it works in interpreter, I did found that bug "fixes"
itself if I enable `DEBUG_STACK_FRAMES` in StackFrameList.cpp, because
that calls `StackFrame::Dump` and that calls
`GetSymbolContext(eSymbolContextEverything)`, which fills the context of
frame on the first breakpoint, therefore it doesn't have to be
recalculated (improperly) on a second frame. However, on first
breakpoint symbol context is calculated for the "call" line, not the
next one, therefore it should be recalculated anyway on a second
breakpoint, and it is done correctly, even though
m_behaves_like_zeroth_frame is still incorrect, as long as
`GetSymbolContext(eSymbolContextEverything)` has been called.

[1] 31e6dbe1c6a6 Fix PC adjustment in StackFrame::GetSymbolContext


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D75975

Files:
  lldb/source/Target/StackFrame.cpp
  lldb/test/API/functionalities/unwind/zeroth_frame/Makefile
  lldb/test/API/functionalities/unwind/zeroth_frame/TestZerothFrame.py
  lldb/test/API/functionalities/unwind/zeroth_frame/main.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D75975.249561.patch
Type: text/x-patch
Size: 5326 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20200311/d85d0af2/attachment.bin>


More information about the lldb-commits mailing list