[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077
show more ...
[lldb] Copy m_behaves_like_zeroth_frame on stack frame updateFix to code from https://reviews.llvm.org/D64993.Field StackFrame::m_behaves_like_zeroth_frame was introduced in commit[1], however t
[lldb] Copy m_behaves_like_zeroth_frame on stack frame updateFix to code from https://reviews.llvm.org/D64993.Field StackFrame::m_behaves_like_zeroth_frame was introduced in commit[1], however that commit hasn't added a copying of the field toUpdatePreviousFrameFromCurrentFrame, therefore the value wouldn't changewhen updating frames to reflect the current situation.The particular scenario, where this matters is following. Assume we havefunction main that invokes function func1. We set breakpoint atfunc1 entry and in main after the func1 call, and do not stop atthe main entry. Therefore, when debugger stops for the first time,func1 is frame#0, while main is frame#1, thusm_behaves_like_zeroth_frame is set to 0 for main frame. Execution isresumed, and stops now in main, where it is now frame#0. However whileupdating the frame object, m_behaves_like_zeroth_frame remains false.This field plays an important role when calculating line information forbacktrace: for frame#0, PC is the current line, therefore lineinformation is retrieved for PC, however for all other frames this isnot the case - calculated PC is a return-PC, i.e. instruction after thefunction call line, therefore for those frames LLDB needs to step backby one instruction. Initial implementation did this strictly for framesthat have index != 0 (and index is updated properly inUpdatePreviousFrameFromCurrentFrame), but m_behaves_like_zeroth_frameadded a capability for middle-of-stack frames to behave in a similarmanner. 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 asnon-zeroth, and would subtract instruction from the PC, and would reportprevious like as current line.The error doesn't manifest itself in LLDB interpreter though - it can bereproduced through LLDB-MI and when using SB API, but not when weinterpreter command "continue" is executed. Honestly, I didn't fullyunderstand why it works in interpreter, I did found that bug "fixes"itself if I enable DEBUG_STACK_FRAMES in StackFrameList.cpp, becausethat calls StackFrame::Dump and that callsGetSymbolContext(eSymbolContextEverything), which fills the context offrame on the first breakpoint, therefore it doesn't have to berecalculated (improperly) on a second frame. However, on firstbreakpoint symbol context is calculated for the "call" line, not thenext one, therefore it should be recalculated anyway on a secondbreakpoint, and it is done correctly, even thoughm_behaves_like_zeroth_frame is still incorrect, as long asGetSymbolContext(eSymbolContextEverything) has been called.[1] 31e6dbe1c6a6 Fix PC adjustment in StackFrame::GetSymbolContextDifferential Revision: https://reviews.llvm.org/D75975Patch by Anton Kolesov <[email protected]>