Reland with changes: the test modified in this change originally failed
on a Debian/x86_64 builder, and I suspect the cause was that lldb looked
up the line location for an artificial frame by subtracting 1 from the
frame's address. For artificial frames, the subtraction must not happen
because the address is already exact.
---
lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).
Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.
Depends on D76336.
rdar://60307600
Differential Revision: https://reviews.llvm.org/D76337
This reverts commit 6905394d15. The
changed test is failing on Debian/x86_64, possibly because lldb is
subtracting an offset from the DW_AT_call_pc address used for the
artificial frame:
http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/7171/steps/test/logs/stdio
/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/tail_call_frames/unambiguous_sequence/main.cpp:6:17: error: CHECK-NEXT: expected string not found in input
// CHECK-NEXT: frame #1: 0x{{[0-9a-f]+}} a.out`func3() at main.cpp:14:3 [opt] [artificial]
^
<stdin>:3:2: note: scanning from here
frame #1: 0x0000000000401127 a.out`func3() at main.cpp:13:4 [opt] [artificial]
lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).
Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.
Depends on D76336.
rdar://60307600
Differential Revision: https://reviews.llvm.org/D76337
There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate
whether the result number should be returned to the pool or not. It
got broken when the PersistentExpressionState was refactored.
This fixes the issue and provides a test of the behavior.
Differential Revision: https://reviews.llvm.org/D76532
Summary:
The interactions between the environment settings (`target.env-vars`,
`target.inherit-env`) and the inferior life-cycle are non-obvious
today. For example, if `target.inherit-env` is set, the `target.env-vars`
setting will be augmented with the contents of the host environment
the first time the launch environment is queried (usually at
launch). After that point, toggling `target.inherit-env` will have no
effect as there's no tracking of what comes from the host and what is
a user setting.
This patch computes the environment every time it is queried rather
than updating the contents of the `target.env-vars` property. This
means that toggling the `target.inherit-env` property later will now
have the intended effect.
This patch also adds a `target.unset-env-vars` settings that one can
use to remove variables from the launch environment. Using this, you
can inherit all but a few of the host environment.
The way the launch environment is constructed is:
1/ if `target.inherit-env` is set, then read the host environment
into the launch environment.
2/ Remove for the environment the variables listed in
`target.unset-env`.
3/ Augment the launch environment with the contents of
`target.env-vars`. This overrides any common values with the host
environment.
The one functional difference here that could be seen as a regression
is that `target.env-vars` will not contain the inferior environment
after launch. The patch implements a better alternative in the
`target show-launch-environment` command which will return the
environment computed through the above rules.
Reviewers: labath, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76470
Summary:
The TargetProperties constructor invokes a series of callbacks to
prime the properties from the default ones. The one callback in
charge of updating the inferior environment was commented out
because it crashed.
The reason for the crash is that TargetProperties is a parent class
of Target and the callbacks were invoked using a Target that was
not fully initialized. This patch moves the initial callback
invocations to a separate function that can be called at the end
the Target constructor, thus preventing the crash.
One existing test had to be modified, because the initialization of
the environment properties now take place at the time the target is
created, not at the first use of the environment (usually launch
time).
The added test checks that the LaunchInfo object returned by
the target has been primed with the values from the settings.
Reviewers: jingham, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76009
The fourth field in the property struct is the default unsigned or enum
value for all types, except for Array and Dictionary types. For those,
it is the element type. During the tablegen conversion, this was
incorrectly translated to DefaultValueUnsigned with a value
corresponding to the OptionValue: enum type. So for
OptionValue::eTypeString this became DefaultUnsignedValue<16>. This
patch extends the tablegen backend to understand ElementType to express
this as ElementType<"String">.
Differential revision: https://reviews.llvm.org/D76535
Summary:
This patch improves step over performance for the case when we are
stepping over a call with a next-branch-breakpoint (see
https://reviews.llvm.org/D58678), and we encounter a stop during the
call. Currently, this causes the thread plan to step-out //each frame//
until it reaches the step-over range. This is a regression introduced by
https://reviews.llvm.org/D58678 (which did improve other things!). Prior
to that change, the step-over plan would always step-out just once.
With this patch, if we find ourselves stopped in a deeper stack frame
and we already have a next branch breakpoint, we simply return from the
step-over plan's ShouldStop handler without pushing the step out plan.
In my experiments this improved the time of stepping over a call that
loads 12 dlls from 14s to 5s. This was in remote debugging scenario with
10ms RTT, the call in question was Vulkan initialization
(vkCreateInstance), which loads various driver dlls. Loading those dlls
must stop on the rendezvous breakpoint, causing the perf problem
described above.
Reviewers: clayborg, labath, jingham
Reviewed By: jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76216
This patch changes the way the StackFrame Recognizers match a certain
frame.
Until now, recognizers could be registered with a function
name but also an alternate symbol.
This change is motivated by a test failure for the Assert frame
recognizer on Linux. Depending the version of the libc, the abort
function (triggered by an assertion), could have more than two
signatures (i.e. `raise`, `__GI_raise` and `gsignal`).
Instead of only checking the default symbol name and the alternate one,
lldb will iterate over a list of symbols to match against.
rdar://60386577
Differential Revision: https://reviews.llvm.org/D76188
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
I believe the actual opcode does not matter because the AVR architecture
is a Harvard architecture that does not support writing to program
memory. Therefore, debuggers and emulators provide hardware breakpoints.
But for some reason, this opcode must be defined or else LLDB will crash
with an assertion error.
Differential Revision: https://reviews.llvm.org/D74255
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] 31e6dbe1c6 Fix PC adjustment in StackFrame::GetSymbolContext
Differential Revision: https://reviews.llvm.org/D75975
Patch by Anton Kolesov <Anton.Kolesov@synopsys.com>
In addition to the commit rG352f16db87f583ec7f55f8028647b5fd8616111f,
this one fixes settings behavior on clearing - the setting should be
reverted to their default value, not an empty one.
Summary:
This is the only real unwinder, and things have been this way for quite
a long time. At this point, the class has accumulated so many features
it is unlikely that anyone will want to reimplement the whole thing.
The class is also fairly closely coupled (through UnwindPlans and
FuncUnwinders) with a lot of other lldb components that it is hard to
imagine a different unwinder implementation being substantially
different without reimplementing all of those.
The existing unwinding functionality is nonetheless fairly complex and
there is space for adding more structure to it, but I believe a more
worthwhile effort would be to take the existing UnwindLLDB class and try
to break it down and introduce extension/customization points, instead
of writing a brand new Unwind implementation.
Reviewers: jasonmolenda, JDevlieghere, xiaobai
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D75848
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
Summary:
It isn't used anywhere (except on imaginary triples like
sparc-apple-ios) and it also violates plugin separation.
This patch deletes it and declares UnwindLLDB to be _the_ lldb unwinder.
Reviewers: jasonmolenda, JDevlieghere, xiaobai
Subscribers: jyknight, mgorny, krytarowski, fedor.sergeev, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D75680
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.
This prevents calling Breakpoint::shared_from_this of an object that is not owned by any shared_ptr.
Differential Revision: https://reviews.llvm.org/D74557
Summary:
This gets rid of some nesting and of the raw char* variable that caused
the memory management bug we hit recently.
This commit also removes the fallback code which should trigger when
the StopInfo provides no stop description. All currently implemented
StopInfos have a `GetDescription()` method that shouldn't return an
empty description.
Reviewers: JDevlieghere, labath, mib
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74157
The lldb sanitizer bot is flagging a container-overflow error after we
introduced test TestWasm.py. MemoryCache::Read didn't behave correctly
in case of partial reads that can happen with object files whose size is
smaller that the cache size. It should return the actual number of bytes
read and not try to fill the buffer with random memory.
Module::GetMemoryObjectFile needs to be modified accordingly, to resize
its buffer to only the size that was read.
Differential Revision: https://reviews.llvm.org/D75200
Comparing those two `const char *` values relies on the assumption that both
strings were created by a ConstString. Let's check that assumption with an
assert as otherwise this code silently does nothing and that's not great.
The two classes are equivalent, except:
- the former uses a llvm::SmallVector (with a configurable size), while
the latter uses std::vector.
- the former has a typo in one of the functions name
This patch just leaves one class, using llvm::SmallVector, and defaults
the small size to zero. This is the same thing we did with the
RangeDataVector class in D56170.
Pass TargetSP to filters' CreateFromStructuredData, don't let them guess
whether target object is managed by a shared_ptr.
Make Breakpoint sure that m_target.shared_from_this() is safe by passing TargetSP
to all its static Create*** member-functions. This should be enough, since Breakpoint's
constructors are private/protected and never called directly (except by Target itself).
The error is: no matching function for call to 'transform(std::string&, std::__cxx11::basic_string<char>::iterator, <unresolved overloaded function type>)'
The fix: replace llvm::transform with an equally simple hand-rolled
loop.
Summary:
These definitions are used to "augment" information received from the remote
target with eh/debug frame and "generic" register numbers.
Besides being verbose, this information was also incomplete (new registers like
xmm16-31 were missing) and sometimes even downright wrong (ymm register
numbers).
Most of this information is available via llvm's MCRegisterInfo. This patch
creates a new class, MCBasedABI, which retrieves the eh and debug frame register
numbers this way. The tricky part here is that the llvm class uses all-caps
register names, whereas lldb register are lowercase, and sometimes called
slightly differently. Therefore this class introduces some hooks to allow a
subclass to customize the MC lookup. The subclass also needs to suply the
"generic" register numbers, as this is an lldb invention.
This patch ports the x86_64 ABI classes to use the new register info mechanism.
It also creates a new "ABIx86_64" class which can be used to house code common
to x86_64 both ABIs. Right now, this just consists of a single function, but
there are plenty of other things that could be moved here too.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74244
SB API clients can describe the failure message in a more natural
way for their UI, this doesn't add information for them.
Differential Revision: https://reviews.llvm.org/D74585
<rdar://problem/49953304>
Summary:
This patch creates a new subclass of the ABI class in order to abstract away the
mechanism in which we "augment" register information. This enables alternate
augmentation strategies to be introduced.
All existing ABI classes have been modified to inherit from RegInfoBasedABI, but
they will be refactored in subsequent patches.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: sdardis, nemanjai, kbarton, jrtc27, atanasyan, jsji, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74243
This reimplements commit 6b2979c123 and updates
the tests to reflect the addition of the alternate symbol attribute.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string lenght and so does StringRef). This patch replaces all those calls
with GetStringRef() which doesn't recompute the length.
Summary:
The return address validation in D71372 will fail if the memory permissions can't be determined. Many embedded stubs either don't implement the qMemoryRegionInfo packet, or don't have memory permissions at all.
Remove the return from the if clause that calls GetLoadAddressPermissions, so this call failing doesn't cause the step out to abort. Instead, assume that the memory permission check doesn't apply to this type of target.
Reviewers: labath, jingham, clayborg, mossberg
Reviewed By: labath, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72513
D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.
I find no easy way how to find out if it gets recognized as
`__assert_fail` or `__GI___assert_fail` as during `Process` ctor
libc.so.6 is not yet loaded by the debuggee.
DWARF symbol `__GI___assert_fail` overrides the ELF symbol `__assert_fail`.
While external debug info (=DWARF) gets disabled for testsuite (D55859)
that sure does not apply for real world usage.
Differential Revision: https://reviews.llvm.org/D74252
This reverts commit cf1046c716.
Reverted: https://reviews.llvm.org/D74252
It fixed testsuite but broke real world functionality where is not used:
settings set symbols.enable-external-lookup false
D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.
On Fedora 30 x86_64 I have:
$ readelf -Ws /lib64/libc.so.6 |grep '^Symbol\|.*assert_fail'
Symbol table '.dynsym' contains 2362 entries:
630: 0000000000030520 70 FUNC GLOBAL DEFAULT 14 __assert_fail@@GLIBC_2.2.5
Symbol table '.symtab' contains 22711 entries:
922: 000000000002275a 15 FUNC LOCAL DEFAULT 14 __assert_fail_base.cold
18044: 0000000000030520 70 FUNC LOCAL DEFAULT 14 __GI___assert_fail
20081: 00000000000303a0 370 FUNC LOCAL DEFAULT 14 __assert_fail_base
21766: 0000000000030520 70 FUNC GLOBAL DEFAULT 14 __assert_fail
The patch should never expect __GI___assert_fail:
.symtab can be present or not but that should not change that
__assert_fail always wins - it is always present from .dynsym and it can
never be overriden by __GI___assert_fail as __GI___assert_fail has only
local binding. Global binding is preferred since D63540.
External debug info symbols do not matter since D55859 (and DWARF should
never be embedded in system libc.so.6).
Differential Revision: https://reviews.llvm.org/D74252
One way to register a recognizer is to use RegularExpressionSP for the
module and symbol.
In order to match a symbol regardless of the module, the recognizer can
be registered with a nullptr for the module. However, this cause the
frame recognizer list command to crash because it calls
RegularExpression::GetText without checking if the shared pointer is valid.
This patch adds checks for the symbol and module RegularExpressionSP.
Differential Revision: https://reviews.llvm.org/D74212
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
In order to synthesize tail call frames, the stack frame list must not
be empty (otherwise, there is no "previous" frame to infer a tail call
from).
This case is hard to hit. To trigger it, we must first fail to push
`unwind_frame_sp` because we either fail to get its SymbolContext, or
given its SymbolContext the GetParentOfInlineScope call fails. This
causes m_concrete_frames_fetched to be incremented while m_frames
remains empty. Then, the next frame in the stack may fail within
SynthesizeTailCallFrames. This crash arose during a kernel debugging
session.
rdar://59147051
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.
Specializations of the Platform class print the kernel after calling the
super method. By printing the kernel at the end in the super class, we
guarantee the order is the same on different platforms.
UserExpression::GetJITModule was used to support an option in
UserExpression::Evaluate that let you hold onto the JIT Module used during
the expression evaluation. This was only actually used in one spot --
REPL::IOHandlerInputComplete. That method didn't actually take use the
JIT module it got back, so this feature was not used in practice.
This means that we can delete the support in UserExpression::Evaluate
and delete the UserExpression::GetJITModule method entirely.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Vedant Kumar