This variable is used to reducing the likelihood of hitting module cache
issues in CI where different branches can potentially run on the same
machine.
This patch exposes the getter and setter methods for the command
interpreter `print_errors` run option.
rdar://74816984
Differential Revision: https://reviews.llvm.org/D98001
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces a new interpreter setting to prevent LLDB from
re-executing the previous command when passing an empty command.
This can be very useful when performing actions that requires a long
time to complete.
To preserve the original behaviour, the setting defaults to `true`.
rdar://74983516
Differential Revision: https://reviews.llvm.org/D97999
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
We have a plugin.process.gdb-remote.packet-timeout setting, which can be
used to control how long the lldb client is willing to wait before
declaring the server side dead. Our test suite makes use of this
feature, and sets the setting value fairly high, as the low default
value can cause flaky tests, particularly on slower bots.
After fixing TestPlatformConnect (one of the few tests exercising the
remote platform capabilities of lldb) in 4b284b9ca, it immediately
started being flaky on the arm bots. It turns out this is because the
packet-timeout setting is not being applied to platform connections.
This patch makes the platform connections also respect the value of this
setting. It also adds a test which checks that the timeout value is
being honored.
Differential Revision: https://reviews.llvm.org/D97769
GDB remote protocol does not specify length of g packet for register read. It depends on remote to include all or exclude certain registers from g packet. In case a register or set of registers is not included as part of g packet then we should fall back to p packet for reading all registers excluded from g packet by remote. This patch adds support for above feature and adds a test-case for the same.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D97498
This patch introduces Scripted Processes to lldb.
The goal, here, is to be able to attach in the debugger to fake processes
that are backed by script files (in Python, Lua, Swift, etc ...) and
inspect them statically.
Scripted Processes can be used in cooperative multithreading environments
like the XNU Kernel or other real-time operating systems, but it can
also help us improve the debugger testing infrastructure by writting
synthetic tests that simulates hard-to-reproduce process/thread states.
Although ScriptedProcess is not feature-complete at the moment, it has
basic execution capabilities and will improve in the following patches.
rdar://65508855
Differential Revision: https://reviews.llvm.org/D95713
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
In order to facilitate the writting of Scripted Processes, this patch
introduces a `ScriptedProcess` python base class in the lldb module.
The base class holds the python interface with all the - abstract -
methods that need to be implemented by the inherited class but also some
methods that can be overwritten.
This patch also provides an example of a Scripted Process with the
`MyScriptedProcess` class.
rdar://65508855
Differential Revision: https://reviews.llvm.org/D95712
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Skip the AVX-related lldb-server test on non-x86 architectures, as they
do not support AVX. While technically the test worked on Linux because
the AVX check would simply return false, other platforms do not provide
such a straightforward way of checking for AVX (especially remotely),
and the results of such check may need to be interpreted specially
for the platform in question.
Differential Revision: https://reviews.llvm.org/D97450
Use realpath() when spawning the executable create_after_attach
to workaround a FreeBSD plugin (and possibly others) problem.
If the executable is started via a path containing a symlink, it is
added to the module list twice -- via the real and apparent path.
This in turn cases the requested breakpoint to resolve twice.
Use realpath() for main program path in lldb-vscode breakpoint tests
to workaround a similar problem. If the passed path does not match
the realpath, lldb-vscode does not report the breakpoints as verified
and causes tests to fail.
Since the underlying problems are non-trivial to fix and the purpose
of these tests is not to reproduce symlink problems, let's apply
trivial workarounds to make them pass.
Differential Revision: https://reviews.llvm.org/D97230
Some implementations of the DeepCopy function called the copy constructor that copied m_parent member instead of setting a new parent. Others just leaved the base class's members (m_parent, m_callback, m_was_set) empty.
One more problem is that not all classes override this function, e.g. OptionValueArgs::DeepCopy produces OptionValueArray instance, and Target[Process/Thread]ValueProperty::DeepCopy produces OptionValueProperty. This makes downcasting via static_cast invalid.
The patch implements idiom "virtual constructor" to fix these issues.
Add a test that checks DeepCopy for correct copying/setting all data members of the base class.
Differential Revision: https://reviews.llvm.org/D96952
Add frame variable dereference suppport to libc++ `std::unique_ptr`.
This change allows for commands like `v *thing_up` and `v thing_up->m_id`. These commands now work the same way they would with raw pointers, and as they would with expression. This is done by adding an unaccounted for child member named `$$dereference$$`.
Without this change, the command would have to be written as `v *thing_up.__value_` or v thing_up.__value_->m_id` which exposes internal structure and is more clumsy to type.
Additionally, the existing tests were updated. See also https://reviews.llvm.org/D97165 which added deref support for `std::shared_ptr`.
Differential Revision: https://reviews.llvm.org/D97524
Add `frame variable` dereference suppport to libc++ `std::shared_ptr`.
This change allows for commands like `v *thing_sp` and `v thing_sp->m_id`. These
commands now work the same way they do with raw pointers. This is done by adding an
unaccounted for child member named `$$dereference$$`.
Also, add API tests for `std::shared_ptr`, previously there were none.
Differential Revision: https://reviews.llvm.org/D97165
This reapplies 7df4eaaa93/D96202, which was reverted due to issues on
windows. These were caused by problems in the computation of the liblldb
directory, which was fixed by D96779.
The original commit message was:
Our test configuration logic assumes that the tests can be run either
with debugserver or with lldb-server. This is not entirely correct,
since lldb server has two "personalities" (platform server and debug
server) and debugserver is only a replacement for the latter.
A consequence of this is that it's not possible to test the platform
behavior of lldb-server on macos, as it is not possible to get a hold of
the lldb-server binary.
One solution to that would be to duplicate the server configuration
logic to be able to specify both executables. However, that seems
excessively redundant.
A well-behaved lldb should be able to find the debug server on its own,
and testing lldb with a different (lldb-|debug)server does not seem very
useful (even in the out-of-tree debugserver setup, we copy the server
into the build tree to make it appear "real").
Therefore, this patch deletes the configuration altogether and changes
the low-level server retrieval functions to be able to both lldb-server
and debugserver paths. They do this by consulting the "support
executable" directory of the lldb under test.
Differential Revision: https://reviews.llvm.org/D96202
VSCode was not being informed whenever a location had been resolved (after being initated as non-resolved), so even though it was actually resolved, the IDE would show a hollow dot (instead of a red dot) because it didn't know about the change.
Differential Revision: https://reviews.llvm.org/D96680
This issue was introduced in https://reviews.llvm.org/D92187.
The guard I'm changing were is supposed to act when linux is loading the linker for the second time (due to differences in paths like symlinks).
This is done by checking `module_sp != m_interpreter_module.lock()` however this will be true when `m_interpreter_module` wasn't initialized, making linux unload the linker module (the most visible result here is that lldb will stop getting notified about new modules loaded by the process, because it can't set the rendezvous breakpoint again after the stepping over it once).
The `m_interpreter_module` is not getting initialize when it goes through this path: dbfdb139f7/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp (L332), which happens when lldb was able to read the address from the dynamic section of the executable.
What I'm not sure about though, is if when we go through this path if we still load the linker twice on linux. If that's the case then it means we need to somehow set the m_interpreter_module instead of the fix I provide here. I've only tested this on Android.
Differential Revision: https://reviews.llvm.org/D96637
Our code for locating the shared library directory works via dladdr (or
the windows equivalent) to locate the path of an address known to reside
in liblldb. This works great for C++ programs, but there's a catch.
When (lib)lldb is used from python (like in our test suite), this dladdr
call will return a path to the _lldb.so (or such) file in the python
directory. To compensate for this, we have code which attempts to
resolve this symlink, to ensure we get the canonical location. However,
here's the second catch.
On windows, this file is not a symlink (but a copy), so this logic
fails. Since most of our other paths are derived from the liblldb
location, all of these paths will be wrong, when running the test suite.
One effect of this was the failure to find lldb-server in D96202.
To fix this issue, I add some windows-specific code to locate the
liblldb directory. Since it cannot rely on symlinks, it works by
manually walking the directory tree -- essentially doing the opposite of
what we do when computing the python directory.
To avoid python leaking back into the host code, I implement this with
the help of a callback which can be passed to HostInfo::Initialize in
order to assist with the directory location. The callback lives inside
the python plugin.
I also strenghten the existing path test to ensure the returned path is
the right one.
Differential Revision: https://reviews.llvm.org/D96779
real_path returns an `std::error_code` which evaluates to `true` in case an
error happens and `false` if not. This code was checking the inverse, so
case-insensitive file systems ended up being detected as case sensitive.
Tested using an LLDB reproducer test as we anyway need a real file system and
also some matching logic to detect whether the respective file system is
case-sensitive (which the test is doing via some Python checks that we can't
really emulate with the usual FileCheck logic).
Fixes rdar://67003004
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D96795
lldb-server can use a named pipe to communicate the port number it is
listening on. This windows bits of this are already implemented, but we
did not have a test for that, most likely because python does not have
native pipe functionality.
This patch implements the windows bits necessary to test this. I'm using
the ctypes package to call the native APIs directly to avoid a
dependency to non-standard python packages. This introduces some amount
of boilerplate, but our named pipe use case is fairly limited, so we
should not end up needing to wrap large chunks of windows APIs.
Surprisingly to changes to lldb-server were needed to make the test
pass.
Differential Revision: https://reviews.llvm.org/D96260
TestMultipleTargets.py fails randomly on Arm/AArch64 Linux buildbot with
no reasonable clues. I am marking it skipped for avoiding LLDB buildbot
failures due to this test.
This test supposed to check the test base we are using for pexpect tests, but instead it used the normal TestBase
class we use for all other tests. TestBase already had the substrs type check since D88792 so this
test was passing because of that.
This just changes the test base of the test to the pexpect one so that the `expect` calls find their intended
target function. Also moves the check to the very start so that we can check the argument without
actually having to start a terminal and all that jazz.
(I found this by accident as D88792 got somehow reverted in a downstream branch so this test started
failing).
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D96556
Multi-configuration generators (such as Visual Studio and Xcode) allow the specification of a build flavor at build time instead of config time, so the lit configuration files need to support that - and they do for the most part. There are several places that had one of two issues (or both!):
1) Paths had %(build_mode)s set up, but then not configured, resulting in values that would not work correctly e.g. D:/llvm-build/%(build_mode)s/bin/dsymutil.exe
2) Paths did not have %(build_mode)s set up, but instead contained $(Configuration) (which is the value for Visual Studio at configuration time, for Xcode they would have had the equivalent) e.g. "D:/llvm-build/$(Configuration)/lib".
This seems to indicate that we still have a lot of fragility in the configurations, but also that a number of these paths are never used (at least on Windows) since the errors appear to have been there a while.
This patch fixes the configurations and it has been tested with Ninja and Visual Studio to generate the correct paths. We should consider removing some of these settings altogether.
Reviewed By: JDevlieghere, mehdi_amini
Differential Revision: https://reviews.llvm.org/D96427
Right now when running `expr --top-level -- void foo() {}`, LLDB just prints a cryptic
`error: Couldn't find $__lldb_expr() in the module` error. The reason for that is
that if we don't have a running process, we try to set our execution policy to always use the
IR interpreter (ExecutionPolicyNever) which works even without a process. However
that code didn't consider the special ExecutionPolicyTopLevel which we use for
top-level expressions. By changing the execution policy to ExecutionPolicyNever,
LLDB thinks we're actually trying to interpret a normal expression inside our
`$__lldb_expr` function and then fails when looking for it.
This just adds an exception for top-level expressions to that code and a bunch of tests.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D91723
Clang emits a warning when accessing an Objective-C getter but not using the result.
This gets triggered when just trying to print a getter value in the expression parser (where
Clang just sees a normal expression like `obj.getter` while parsing).
This patch just disables the warning in the expression parser (similar to what we do with
the C++ equivalent of just accessing a member variable but not doing anything with it).
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D94307
Our test configuration logic assumes that the tests can be run either
with debugserver or with lldb-server. This is not entirely correct,
since lldb server has two "personalities" (platform server and debug
server) and debugserver is only a replacement for the latter.
A consequence of this is that it's not possible to test the platform
behavior of lldb-server on macos, as it is not possible to get a hold of
the lldb-server binary.
One solution to that would be to duplicate the server configuration
logic to be able to specify both executables. However, that seems
excessively redundant.
A well-behaved lldb should be able to find the debug server on its own,
and testing lldb with a different (lldb-|debug)server does not seem very
useful (even in the out-of-tree debugserver setup, we copy the server
into the build tree to make it appear "real").
Therefore, this patch deletes the configuration altogether and changes
the low-level server retrieval functions to be able to both lldb-server
and debugserver paths. They do this by consulting the "support
executable" directory of the lldb under test.
Differential Revision: https://reviews.llvm.org/D96202
Although it is located under tools/lldb-server, this test is very
different that other lldb-server tests. The most important distinction
is that it does not test lldb-server directly, but rather interacts with
it through the lldb client. It also tests the relevant client
functionality (the platform connect command, which is even admitted in
the test name). The fact that this test is structured as a lldb-server
test means it cannot access most of the goodies available to the
"normal" lldb tests (the runCmd function, which it reimplements; the
run_break_set_by_symbol utility function; etc.).
This patch makes it a full-fledged lldb this, and rewrites the relevant
bits to make use of the standard features. I also move the test into the
"commands" subtree to better reflect its new status.
BlockPointerSyntheticFrontEnd does a CopyType which results in it copying the type
back into its own context. This will result in a call to ASTImporterDelegate::setOrigin
with &decl->getASTContext() == origin.ctx this can result in an infinite recursion
later on in ASTImporter since it will attempt to find the decl in its origin which will be itself.
Differential Revision: https://reviews.llvm.org/D96366
There is a .categories file in the python_api directory that makes all nested tests
belong to the category "pyapi". The decorator is unnecessary for these tests.
Native register descriptions in LLDB specify lldb register numbers in
value_regs and invalidate_regs lists. These register numbers may not
match with Process gdb-remote register numbers which are generated by
native process after counting all registers in its register sets.
It was coincidentally not causing any problems as we never came across
a native target with dynamically changing register sets and register
numbers generated by counter matched with LLDB native register numbers.
This came up while testing target AArch64 SVE which can choose register
sets based on underlying hardware.
This patch fixes this behavior and always tries to use remote register
numbers while reading/writing registers over gdb-remote protocol.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D77043
This patch tries to improve memory-read from core files
(in order to improve disassembly functionality).
I am using RHEL 7.7 (linux kernel 3.10) and for a lot of cases,
I was not able to disassemble some functions from backtrace when
debugging crashes from core files. It outputs some dummy code.
The cause of the problem was the fact we are returning all the zeros
from ProcessElfCore::ReadMemory() that is being called within
Disassembler::ParseInstructions() and it disassembles some dummy
opcodes from the buffer returned. Therefore, we are removing zero
bytes filling (padding) completely.
Differential Revision: https://reviews.llvm.org/D93939
This test passes on arm64 (Apple Silicon). I assume that "aarch64" still
ensures this gets skipped on Linux. I don't have access to such and
environment so I'll have to rely on the bot complaining.
Replace the dotest command line options and various cmake variables,
which are used for passing the locations of llvm tools to the API tests
with a single variable, which points to the directory these tools are
placed in. Besides reducing repetition, this also makes things more
similar to how "normal" llvm tests are configured.
Differential Revision: https://reviews.llvm.org/D95261
I switched the watch simulator test from i386 to using x86_64, but
apparently that's not supported on the bots. Rollback to using i386 and
solve the original issue by passing the target, similar to what I did
in TestSimulatorPlatform.py.
Honor the CPU type (and subtype) when launching the inferior on macOS.
Part of this functionality was thought to be no longer needed and
removed in 85bd436961, however it's still
needed, for example to launch binaries under Rosetta 2 on Apple Silicon.
This patch will use posix_spawnattr_setarchpref_np if available and
fallback to posix_spawnattr_setbinpref_np if not.
Differential revision: https://reviews.llvm.org/D95922
Convert `assertTrue(a == b)` to `assertEqual(a, b)` to produce better failure messages.
These were mostly done via regex search & replace, with some manual fixes.
Differential Revision: https://reviews.llvm.org/D95813
This reverts commit 754ab803b8.
As pointed out in https://reviews.llvm.org/D95761, this patch could lead to
having the wrong execution context in some situations (thanks Jim!).
D92164 is addressing the same issue and will replace this patch, so I'll
revert this one.
