StackFrame::GetValueObjectForFrameVariable holds the StackFrame lock too long.

This can cause a deadlock if other threads use the common pattern of
"lock the StackFrameList, get a frame, lock the St

StackFrame::GetValueObjectForFrameVariable holds the StackFrame lock too long.

This can cause a deadlock if other threads use the common pattern of
"lock the StackFrameList, get a frame, lock the StackFrame."

Differential Revision: https://reviews.llvm.org/D130524

show more ...

Reland "[LLDB][NFC] Decouple dwarf location table from DWARFExpression."

This reland 227dffd0b6d78154516ace45f6ed28259c7baa48 and
562c3467a6738aa89203f72fc1d1343e5baadf3c with failed api tests fixed

Reland "[LLDB][NFC] Decouple dwarf location table from DWARFExpression."

This reland 227dffd0b6d78154516ace45f6ed28259c7baa48 and
562c3467a6738aa89203f72fc1d1343e5baadf3c with failed api tests fixed by keeping
function base file addres in DWARFExpressionList.

show more ...

Revert "[LLDB][NFC] Decouple dwarf location table from DWARFExpression."

This reverts commit 227dffd0b6d78154516ace45f6ed28259c7baa48 and its
follow up 562c3467a6738aa89203f72fc1d1343e5baadf3c becau

Revert "[LLDB][NFC] Decouple dwarf location table from DWARFExpression."

This reverts commit 227dffd0b6d78154516ace45f6ed28259c7baa48 and its
follow up 562c3467a6738aa89203f72fc1d1343e5baadf3c because it breaks a
bunch of tests on GreenDragon:

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45155/

show more ...

[LLDB][NFC] Decouple dwarf location table from DWARFExpression.

Differential Revision: https://reviews.llvm.org/D125509

[lldb] Use value_or instead of getValueOr (NFC)

[lldb] Support non-pointer implicit this/self in GetValueForVariableExpressionPath

The `frame variable` command supports an implicit `this`/`self`, allowing a
user to run `v some_field` instead of `

[lldb] Support non-pointer implicit this/self in GetValueForVariableExpressionPath

The `frame variable` command supports an implicit `this`/`self`, allowing a
user to run `v some_field` instead of `v this->some_field`. However, some
languages have non-pointer `this`/`self` types (for example, Swift).

This change adds support for non-pointer implicit `this`/`self`. This is done
by consulting the type of the instance variable. If the type is known to be
non-pointer, the dot operator is used instead of the arrow operator.

The C language of families each have a pointer instance type, which makes
testing of this difficult. Tests for this feature will be done in the Swift
downstream fork, as Swift's `self` is a non-pointer (reference) type.

rdar://82095148

Reviewed By: aprantl

Differential Revision: https://reviews.llvm.org/D127605

show more ...

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
inf

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.

show more ...

[lldb] Convert "LLDB" log channel to the new API

[lldb] Correct \params to \param in StackFrame Doxygen comments

[lldb/Target] Refine source display warning for artificial locations (NFC)

This is a post-review update for D115313, to rephrase source display
warning messages for artificial locations, making them

[lldb/Target] Refine source display warning for artificial locations (NFC)

This is a post-review update for D115313, to rephrase source display
warning messages for artificial locations, making them more
understandable for the end-user.

Differential Revision: https://reviews.llvm.org/D115461

Signed-off-by: Med Ismail Bennani <[email protected]>

show more ...

[lldb/Target] Slide source display for artificial locations at function start

It can happen that a line entry reports that some source code is located
at line 0. In DWARF, line 0 is a special locati

[lldb/Target] Slide source display for artificial locations at function start

It can happen that a line entry reports that some source code is located
at line 0. In DWARF, line 0 is a special location which indicates that
code has no 1-1 mapping with source.

When stopping in one of those artificial locations, lldb doesn't know which
line to display and shows the beginning of the file instead.

This patch mitigates this behaviour by checking if the current symbol context
of the line entry has a matching function, in which case, it slides the
source listing to the start of that function.

This patch also shows the user a warning explaining why lldb couldn't
show sources at that location.

rdar://83118425

Differential Revision: https://reviews.llvm.org/D115313

Signed-off-by: Med Ismail Bennani <[email protected]>

show more ...

Target::ReadMemory read from read-only binary file Section, not memory

Commiting this patch for Augusto Noronha who is getting set
up still.

This patch changes Target::ReadMemory so the default beh

Target::ReadMemory read from read-only binary file Section, not memory

Commiting this patch for Augusto Noronha who is getting set
up still.

This patch changes Target::ReadMemory so the default behavior
when a read is in a Section that is read-only is to fetch the
data from the local binary image, instead of reading it from
memory. Update all callers to use their old preferences
(the old prefer_file_cache bool) using the new API; we should
revisit these calls and see if they really intend to read
live memory, or if reading from a read-only Section would be
equivalent and important for performance-sensitive cases.

rdar://30634422

Differential revision: https://reviews.llvm.org/D100338

show more ...

[lldb] Remove unused StackFrame::TrackGlobalVariable

Last used by the Go plugin which was removed in https://reviews.llvm.org/D54057.

LanguageRuntime for 0th frame unwind, simplify getting pc-for-symbolication

Add calls into LanguageRuntime when finding the unwind method to
use out of the 0th (currently executing) stack frame.

Al

LanguageRuntime for 0th frame unwind, simplify getting pc-for-symbolication

Add calls into LanguageRuntime when finding the unwind method to
use out of the 0th (currently executing) stack frame.

Allow for the LanguageRuntimes to indicate if this stack frames
should be treated like a zeroth-frame -- symbolication should be
done based on the saved pc address, not decremented like normal ABI
function calls.

Add methods to RegisterContext and StackFrame to get a pc value
suitable for symbolication, to reduce the number of places in lldb
where we decrement the saved pc values before symbolication.

<rdar://problem/70398009>
Differential Revision: https://reviews.llvm.org/D97644

show more ...

[lldb] Fix a regression introduced by D75730

In a new Range class was introduced to simplify and the Disassembler API
and reduce duplication. It unintentionally broke the
SBFrame::Disassemble functi

[lldb] Fix a regression introduced by D75730

In a new Range class was introduced to simplify and the Disassembler API
and reduce duplication. It unintentionally broke the
SBFrame::Disassemble functionality because it unconditionally converts
the number of instructions to a Range{Limit::Instructions,
num_instructions}. This is subtly different from the previous behavior,
where now we're passing a Range and assume it's valid in the callee, the
original code would propagate num_instructions and the callee would
compare the value and decided between disassembling instructions or
bytes.

Unfortunately the existing tests was not particularly strict:

disassembly = frame.Disassemble()
self.assertNotEqual(len(disassembly), 0, "Disassembly was empty.")

This would pass because without this patch we'd disassemble zero
instructions, resulting in an error:

(lldb) script print(lldb.frame.Disassemble())
error: error reading data from section __text

Differential revision: https://reviews.llvm.org/D89925

show more ...

Unify the return value of GetByteSize to an llvm::Optional<uint64_t> (NFC-ish)

This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like th

Unify the return value of GetByteSize to an llvm::Optional<uint64_t> (NFC-ish)

This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like the methods in
CompilerType do. This means fewer magic 0 values, which could fix bugs
down the road in languages where types can have a size of zero, such
as Swift and C (but not C++).

Differential Revision: https://reviews.llvm.org/D84285

This re-lands the patch with bogus :m_byte_size(0) initalizations removed.

show more ...

Temporarily Revert "Unify the return value of GetByteSize to an llvm::Optional<uint64_t> (NFC-ish)"
as it's causing numerous (176) test failures on linux.

This reverts commit 1d9b860fb6a85df33fd52fc

Temporarily Revert "Unify the return value of GetByteSize to an llvm::Optional<uint64_t> (NFC-ish)"
as it's causing numerous (176) test failures on linux.

This reverts commit 1d9b860fb6a85df33fd52fcacc6a5efb421621bd.

show more ...

Unify the return value of GetByteSize to an llvm::Optional<uint64_t> (NFC-ish)

This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like th

Unify the return value of GetByteSize to an llvm::Optional<uint64_t> (NFC-ish)

This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like the methods in
CompilerType do. This means fewer magic 0 values, which could fix bugs
down the road in languages where types can have a size of zero, such
as Swift and C (but not C++).

Differential Revision: https://reviews.llvm.org/D84285

show more ...

[lldb] Store StackFrameRecognizers in the target instead of a global list

Summary:

Currently the frame recognizers are stored in a global list (the list in the
StackFrameRecognizersManagerImpl sing

[lldb] Store StackFrameRecognizers in the target instead of a global list

Summary:

Currently the frame recognizers are stored in a global list (the list in the
StackFrameRecognizersManagerImpl singleton to be precise). All commands and
plugins that modify the list are just modifying that global list of recognizers
which is shared by all Target and Debugger instances.

This is clearly against the idea of LLDB being usable as a library and it also
leads to some very obscure errors as now multiple tests are sharing the used
frame recognizers. For example D83400 is currently failing as it reorders some
test_ functions which permanently changes the frame recognizers of all
debuggers/targets. As all frame recognizers are also initialized in a 'once'
guard, it's also impossible to every restore back the original frame recognizers
once they are deleted in a process.

This patch just moves the frame recognizers into the current target. This seems
the way everyone assumes the system works as for example the assert frame
recognizers is using the current target to find the function/so-name to look for
(which only works if the recognizers are stored in the target).

Reviewers: jingham, mib

Reviewed By: jingham, mib

Subscribers: MrHate, JDevlieghere

Differential Revision: https://reviews.llvm.org/D83757

show more ...

Fix error handling after [<index>] in 'frame variable'

Summary:
This fixes a bug where

frame var a[0]+5

returns the value a[0] without any warning because the current logic simply ignores everythi

Fix error handling after [<index>] in 'frame variable'

Summary:
This fixes a bug where

frame var a[0]+5

returns the value a[0] without any warning because the current logic simply ignores everything after ']' as long as there is no '.', '-' or '[' in the rest of the string.

The fix simplifies the termination condition of the expression path parsing loop to check if have a non-empty remaining string to parse. Previously, the condition checked if a separator was found. That condition coincided with the remaining string-to-parse condition except for the buggy indexed case where non-empty string was left ("+5" in the example above), but the separator index was 'npos'.

Reviewed By: teemperor, labath

Differential Revision: https://reviews.llvm.org/D79404

show more ...

[lldb] NFC: Fix trivial typo in comments, documents, and messages

Differential Revision: https://reviews.llvm.org/D77460

[lldb] Copy m_behaves_like_zeroth_frame on stack frame update

Fix 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 update

Fix 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 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

Differential Revision: https://reviews.llvm.org/D75975

Patch by Anton Kolesov <[email protected]>

show more ...

[lldb] Reduce duplication in the Disassembler class

Summary:
The class has two pairs of functions whose functionalities differ in
only how one specifies how much he wants to disasseble. One limits t

[lldb] Reduce duplication in the Disassembler class

Summary:
The class has two pairs of functions whose functionalities differ in
only how one specifies how much he wants to disasseble. One limits the
process by the size of the input memory region. The other based on the
total amount of instructions disassembled. They also differ in various
features (like error reporting) that were only added to one of the
versions.

There are various ways in which this could be addressed. This patch
does it by introducing a helper struct called "Limit", which is
effectively a pair specifying the value that you want to limit, and the
actual limit itself.

Reviewers: JDevlieghere

Subscribers: sdardis, jrtc27, atanasyan, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D75730

show more ...

[lldb] s/ExecutionContext/Target in Disassembler

Some functions in this file only use the "target" component of an
execution context. Adjust the argument lists to reflect that.

This avoids some def

[lldb] s/ExecutionContext/Target in Disassembler

Some functions in this file only use the "target" component of an
execution context. Adjust the argument lists to reflect that.

This avoids some defensive null checks and simplifies most of the
callers.

show more ...

[lldb] Remove unused parameter from ValueObject::GetExpressionPath

I previously removed the code in ValueObject::GetExpressionPath that
took advantage of the parameter `qualify_cxx_base_classes`. As

[lldb] Remove unused parameter from ValueObject::GetExpressionPath

I previously removed the code in ValueObject::GetExpressionPath that
took advantage of the parameter `qualify_cxx_base_classes`. As a result,
this is now unused and can be removed.

show more ...