Summary:
This seems only useful for debugging and it's just plainly printf'ing to the console instead
of some log, so let's remove this.
Reviewers: #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76699
Files imported by the script interpreter aren't opened by LLDB so they
don't end up in the reproducer. The solution is to explicitly add them
to the FileCollector.
Differential revision: https://reviews.llvm.org/D76626
Summary:
Detection of C strings does not work well for pointers. If the value object holding a (char*) pointer does not have an address (e.g., if it is a temp), the value is not considered a C string and its formatting is left to DumpDataExtractor rather than the special handling in ValueObject::DumpPrintableRepresentation. This leads to inconsistent outputs, e.g., in escaping non-ASCII characters. See the test for an example; the second test expectation is not met (without this patch). With this patch, the C string detection only insists that the pointer value is valid. The patch makes the code consistent with how the pointer is obtained in ValueObject::ReadPointedString.
Reviewers: teemperor
Reviewed By: teemperor
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76650
Summary:
The default behavior of Platform::PutFile is to open the file and
truncate it if it already exists. This works fine and is a sensible
default, but it interacts badly with code-signing on iOS, as doing so
invalidates the signature of the file (even if the new content has a
valid code signature).
We have a couple tests which on purpose reload a different binary with
the same name. Those tests are currently broken because of the above
interaction.
This patch simply makes the Darwin platform unconditionally delete the
destination file before sending the new one to work around this issue.
Reviewers: jasonmolenda
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76450
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
This adds a formatter for libc++ std::unique_ptr.
I also refactored GetValueOfCompressedPair(...) out of LibCxxList.cpp since I need the same functionality and it made sense to share it.
Differential Revision: https://reviews.llvm.org/D76476
The newly introduced tests for unsetting environment variables
is failing on Windows. Skip the test there to allow investigation.
It seems like setting inherit-env to false was never tested
before. Could it be that the Windows process launcher doesn't
honor this setting?
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:
When no arguments or environment is provided to SBTarget::LaunchSimple,
make it use the values surrently set in the target properties. You can
get the current behavior back by passing an empty array instead.
It seems like using the target defaults is a much more intuitive
behavior for those APIs. It's unllikely that anyone passed NULL/None to
this API after having set properties in order to explicitely ignore them.
One direct application of this change is within the testsuite. We have
plenty of tests calling LaunchSimple and passing None as environment.
If you passed --inferior-env to dotest.py to, for example, set
(DY)LD_LIBRARY_PATH, it wouldn't be taken into account.
Reviewers: jingham, labath, #libc_abi!
Subscribers: libcxx-commits, lldb-commits
Tags: #lldb, #libc_abi
Differential Revision: https://reviews.llvm.org/D76045
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
Summary:
LLDB keeps statistics of how many expression evaluations are 'successful' and 'failed'
which are updated after each expression evaluation (assuming statistics are enabled).
From what I understand the idea is that this could be used to define how well LLDB's
expression evaluator is working.
Currently all expressions are considered successful unless the user passes an explicit
positive element counting to the expression command (with the `-Z` flag) and then passes
an expression that successfully evaluates to a type that doesn't support element counting.
Expressions that fail to parse, execute or any other outcome are considered successful
at the moment which means we nearly always have a 100% expression evaluation
success rate.
This patch makes that expressions that fail to parse or execute to count as failed
expressions.
We can't know whether the expression failed because of an user error
of because LLDB couldn't correctly parse/compile it, but I would argue that this is
still an improvement. Assuming that the percentage of valid user expressions stays
mostly constant over time (which seems like a reasonable assumption), then this
way we can still see if we are doing relatively better/worse from release to release.
Reviewers: davide, aprantl, JDevlieghere
Reviewed By: aprantl
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D76280
Summary: Inspired by https://reviews.llvm.org/D74636, I'm introducing a basic version of Environment in the API. More functionalities can be added as needed.
Reviewers: labath, clayborg
Subscribers: mgorny, lldb-commits, diazhector98
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76111
Summary:
If no custom launching is used, lldb-vscode launches a program with an empty environment by default. In some scenarios, the user might want to simply use the same environment as the IDE to have a set of working environment variables (e.g. PATH wouldn't be empty). In fact, most DAPs in VSCode have this behavior by default. In other cases the user definitely needs to set their custom environment, which is already supported. To make the first case easier for the user (e.g. not having to copy the PATH to the launch.json every time they want to debug simple programs that rely on PATH), a new option is now offered. inheritEnvironment will launch the program copying its own environment, and it's just a boolean flag.
{F11347695}
Reviewers: clayborg, aadsm, diazhector98, kusmour
Subscribers: labath, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74636
Summary:
https://reviews.llvm.org/D65363 introduced the launchCommands argument. However, it did not add
a corresponding definition in the package.json
Reviewers: clayborg, labath, kusmour, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76529
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: Inspired by https://reviews.llvm.org/D74636, I'm introducing a basic version of Environment in the API. More functionalities can be added as needed.
Reviewers: labath, clayborg
Subscribers: mgorny, lldb-commits, diazhector98
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76111
Summary:
On Linux, when executing lldb-vscode on a remote machine, lldb-vscode doesn't die after the debug session ends. It keeps trying to read JSON input to no avail.
This diff indicates lldb-vscode to stop reading after a termination event has been processed.
Reviewers: clayborg, aadsm, kusmour
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76314
If LLDB attaches to an already running target, then structure SBAttachInfo is
used instead of SBLaunchInfo. lldb-vscode function request_attach sets some
values to g_vsc.launch_info, however this field is then not passed anywhere, so
this action has no effect. This commit removes invocation of
SBLaunchInfo::SetDetachOnError, which has no equivalent in SBAttachInfo.
File package.json doesn't describe detachOnError property for "attach" request
type, therefore it is not needed to update it.
Differential Revision: https://reviews.llvm.org/D76351
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 is D68010 but I also set the new parameter in LibStdcpp.cpp to fix
the Debian tests).
Summary:
Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).
It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string
length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.
This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly
was the original purpose of this magic value).
Reviewers: aprantl, JDevlieghere, shafik
Reviewed By: aprantl
Subscribers: christof, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68010
Currently when an expression fails to parse and we have a FixIt, we keep
the failed UserExpression around while trying to parse the expression with
applied fixits. This means that we have this rather confusing control flow:
1. Original expression created and parsing attempted.
2. Expression with applied FixIts is created and parsing attempted.
3. Original expression is destroyed and parser deconstructed.
4. Expression with applied FixIts is destroyed and parser deconstructed.
This patch just deletes the original expression so that step 2 and 3 are
swapped and the whole process looks more like just sequentially parsing two
expressions (which is what we actually do here).
Doesn't fix anything just makes the code less fragile.
Summary:
TestInlineStepping tests LLDB's ability to step in the presence of
inline frames. The testcase source has a number of functions and some
of them are marked `always_inline`.
The test is built around the assumption that the inline function will
be fully represented once inlined, but this is not true with the
current arm64 code generation. For example:
void caller() {
always_inline_function(); // Step here
}
When stppeing into `caller()` above, you might immediatly end up in
the inlines frame for `always_inline_function()`, because there might
literally be no code associated with `caller()` itself.
This patch hacks around the issue by adding an `asm volatile("nop")`
on some lines with inlined calls where we expect to be able to
step. Like so:
void caller() {
asm volatile("nop"); always_inline_function(); // Step here
}
This guarantees there is always going to be one instruction for this
line in the caller.
Reviewers: labath, jingham
Subscribers: kristof.beyls, danielkiss, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76406
Summary:
TestBuiltinTrap fail on darwin embedded because the `__builin_trap`
builtin doesn't get any line info attached to it by clang when
building for arm64.
The test was already XFailed for linux arm(64), I presume for the same
reasons. This patch just XFails it independently of the platform.
Reviewers: labath
Subscribers: kristof.beyls, danielkiss, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76408
This reverts commit 939ca455e7.
This failed on the debian bot for some reason:
File "/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/TestDataFormatterStdString.py", line 67, in test_with_run_command
"s summary wrong")
AssertionError: 'L"hello world! מזל טוב!\\0!\\0!!!!\\0\\0A\\0\\U0000fffd\\U0000fffd\\U0000fffd\\ [truncated]... != 'L"hello world! מזל טוב!"'
Diff is 2156 characters long. Set self.maxDiff to None to see it. : s summary wrong
Summary:
Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).
It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string
length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.
This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly
was the original purpose of this magic value).
Reviewers: aprantl, JDevlieghere, shafik
Reviewed By: aprantl
Subscribers: christof, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68010
This test was stripping a binary generated by Makefile.rules which is
potentially codesigned. Stripping invalidates the code signature, so
we might need to re-sign after stripping.
The test was stripping the binaries from the Python
code. Unfortunately, if running on darwin embedded in a context that
requires code signing, the stripping was invalidating the signature,
thus breaking the test.
This patch moves the stripping to the Makefile and resigns the
stripped binaries if required.
It was an inline test before. Clang stopped emitting line information
for the TLS initialization and the inline test didn't have a way to
break before it anymore.
This rewrites the test as a full-fldeged python test and improves the
checking of the error case to verify that the failure we are looking
for is related to the TLS setup not being complete.