This adds support for reading AArch64 Pointer Authentication regset
from elf-core file. Also includes a test-case for the same. Furthermore
there is also a slight refactoring of RegisterContextPOSIXCore_arm64
members and constructor. linux-aarch64-pac.core file is generated using
lldb/test/API/functionalities/postmortem/elf-core/main.c with following
clang arguments:
-march=armv8.5-a -mbranch-protection=pac-ret+leaf -nostdlib -static -g
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D99941
AArch64 kernel builds default to having /smaps and
the "VmFlags" line was added in 3.8. Long before MTE
was supported.
So we can assume that if you're AArch64 with MTE,
you can run this test.
The previous method of checking had a race condition
where the process we read smaps for, could finish before
we get to read the file.
I explored some alternatives but in the end I think
it's fine to just assume we have what we need.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D100493
When the user running LLDB with default settings sees the fixit
notification it means that the auto-applied fixit didn't work. This
patch shows the underlying error message instead of just the fixit to
make it easier to understand what the error in the expression was.
Differential Revision: https://reviews.llvm.org/D101333
Remove hardcoded platform list for QPassSignals, qXfer:auxv:read
and qXfer:libraries-svr4:read and instead query the process plugin
via the GetSupportedExtensions() API.
Differential Revision: https://reviews.llvm.org/D101241
The test added in D100977 is failing to compile on these platforms. This seems
to be caused by GCC, MSVC and Clang@Windows rejecting the code because
`ToLayout` isn't complete when pointer_to_member_member is declared (even though
that seems to be valid code).
This also reverts the test changes in the lazy-loading test from D100977 as
that failed for the same reason.
Update lldb-server to not use fork or vfork on watchOS and tvOS as these
functions are explicitly marked unavailable there.
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:304:11:
error: 'fork' is unavailable: not available on watchOS
if (fork() == 0)
^
WatchSimulator6.2.sdk/usr/include/unistd.h:447:8: note: 'fork' has been
explicitly marked unavailable here
pid_t fork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
^
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:307:11:
error: 'vfork' is unavailable: not available on watchOS
if (vfork() == 0)
^
WatchSimulator6.2.sdk/usr/include/unistd.h:602:8: note: 'vfork' has been
explicitly marked unavailable here
pid_t vfork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
^
Add a NativeDelegate API to pass new processes (forks) to LLGS,
and support detaching them via the 'D' packet. A 'D' packet without
a specific PID detaches all processes, otherwise it detaches either
the specified subprocess or the main process, depending on the passed
PID.
Differential Revision: https://reviews.llvm.org/D100191
Introduce a NativeProcessProtocol API for indicating support for
protocol extensions and enabling them. LLGS calls
GetSupportedExtensions() method on the process factory to determine
which extensions are supported by the plugin. If the future is both
supported by the plugin and reported as supported by the client, LLGS
enables it and reports to the client as supported by the server.
The extension is enabled on the process instance by calling
SetEnabledExtensions() method. This is done after qSupported exchange
(if the debugger is attached to any process), as well as after launching
or attaching to a new inferior.
The patch adds 'fork' extension corresponding to 'fork-events+'
qSupported feature and 'vfork' extension for 'vfork-events+'. Both
features rely on 'multiprocess+' being supported as well.
Differential Revision: https://reviews.llvm.org/D100153
- The register encoding state in the JSON crashlog format changes.
Update the parser accordingly.
- Print the register state when printing the symbolicated thread.
The `--allow-jit` flag allows the user to force the IR interpreter to run the
provided expression.
The `--top-level` flag parses and injects the code as if its in the top level
scope of a source file.
Both flags just change the ExecutionPolicy of the expression:
* `--allow-jit true` -> doesn't change anything (its the default)
* `--allow-jit false` -> ExecutionPolicyNever
* `--top-level` -> ExecutionPolicyTopLevel
Passing `--allow-jit false` and `--top-level` currently causes the `--top-level`
to silently overwrite the ExecutionPolicy value that was set by `--allow-jit
false`. There isn't any ExecutionPolicy value that says "top-level but only
interpret", so I would say we reject this combination of flags until someone
finds time to refactor top-level feature out of the ExecutionPolicy enum.
The SBExpressionOptions suffer from a similar symptom as `SetTopLevel` and
`SetAllowJIT` just silently disable each other. But those functions don't have
any error handling, so not a lot we can do about this in the meantime.
Reviewed By: labath, kastiglione
Differential Revision: https://reviews.llvm.org/D91780
At the moment the expression parser doesn't support evaluating expressions in
static member functions and just pretends the expression is evaluated within a
non-member function. This causes that all static members are inaccessible when
doing unqualified name lookup.
This patch adds support for evaluating in static member functions. It
essentially just does the same setup as what LLDB is already doing for
non-static member functions (i.e., wrapping the expression in a fake member
function) with the difference that we now mark the wrapping function as static
(to prevent access to non-static members).
Reviewed By: shafik, jarin
Differential Revision: https://reviews.llvm.org/D81550
Ever since Dave Zarzycki's patch to sort test start times based on prior
test timing data (https://reviews.llvm.org/D98179) the test suite aborts
with a SIGHUP. I don't believe his patch is to blame, but rather
uncovers an preexisting issue by making test runs more deterministic.
I was able to narrow down the issue to TestSimulatorPlatform.py. The
issue also manifests itself on the standalone bot on GreenDragon [1].
This patch disables the test until we can figure this out.
[1] http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/
rdar://76995109
VSCode doesn't render multiple variables with the same name in the variables view. It only renders one of them. This is a situation that happens often when there are shadowed variables.
The nodejs debugger solves this by adding a number suffix to the variable, e.g. "x", "x2", "x3" are the different x variables in nested blocks.
In this patch I'm doing something similar, but the suffix is " @ <file_name:line>), e.g. "x @ main.cpp:17", "x @ main.cpp:21". The fallback would be an address if the source and line information is not present, which should be rare.
This fix is only needed for globals and locals. Children of variables don't suffer of this problem.
When there are shadowed variables
{F16182150}
Without shadowed variables
{F16182152}
Modifying these variables through the UI works
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D99989
In certain occasions times, like when LLDB is initializing and
evaluating the .lldbinit files, it tries to print to stderr and stdout
directly. This confuses the IDE with malformed data, as it talks to
lldb-vscode using stdin and stdout following the JSON RPC protocol. This
ends up terminating the debug session with the user unaware of what's
going on. There might be other situations in which this can happen, and
they will be harder to debug than the .lldbinit case.
After several discussions with @clayborg, @yinghuitan and @aadsm, we
realized that the best course of action is to simply redirect stdout and
stderr to the console, without modifying LLDB itself. This will prove to
be resilient to future bugs or features.
I made the simplest possible redirection logic I could come up with. It
only works for POSIX, and to make it work with Windows should be merely
changing pipe and dup2 for the windows equivalents like _pipe and _dup2.
Sadly I don't have a Windows machine, so I'll do it later once my office
reopens, or maybe someone else can do it.
I'm intentionally not adding a stop-redirecting logic, as I don't see it
useful for the lldb-vscode case (why would we want to do that, really?).
I added a test.
Note: this is a simpler version of D80659. I first tried to implement a
RIIA version of it, but it was problematic to manage the state of the
thread and reverting the redirection came with some non trivial
complexities, like what to do with unflushed data after the debug
session has finished on the IDE's side.
This diff ass postRunCommands, which are the counterpart of the preRunCommands. TThey will be executed right after the target is launched or attached correctly, which means that the targets can assume that the target is running.
Differential Revision: https://reviews.llvm.org/D100340
Add initial tests for reading register sets from core dumps. This
includes a C++ program to write registers and dump core, resulting core
dumps for Linux, FreeBSD and NetBSD, and the tests to verify them.
The tests are split into generic part, verifying user-specified register
values, and coredump-specific tests that verify memory addresses that
differ for every dump.
At this moment, all platforms support GPRs and FPRs up to XMM for amd64
target. The i386 target does not work on NetBSD at all, and is missing
FPRs entirely on FreeBSD.
Differential Revision: https://reviews.llvm.org/D91963
The test had a race that could cause two threads to end up with the same
"thread local" value. I believe this would not cause the test to fail,
but it could cause it to succeed even when the functionality is broken.
The new implementation removes this uncertainty, and removes a lot of
cruft left over from the time this test was written using pthreads.
The code used the total number of symbols to create a symbol ID for the
synthetic symbols. This is not correct because the IDs of real symbols
can be higher than their total number, as we do not add all symbols (and
in particular, we never add symbol zero, which is not a real symbol).
This meant we could have symbols with duplicate IDs, which caused
problems if some relocations were referring to the duplicated IDs. This
was the cause of the failure of the test D97786.
This patch fixes the code to use the ID of the highest (last) symbol
instead.
DWARF allows .dwo file paths to be relative rather than absolute. When
they are relative, DWARF uses DW_AT_comp_dir to find the .dwo
file. DW_AT_comp_dir can also be relative, making the entire search
patch for the .dwo file relative. In this case, LLDB currently
searches relative to its current working directory, i.e. the directory
from which the debugger was launched. This is not right, as the
compiler, which generated the relative paths, can have no idea where
the debugger will be launched. The correct thing is to search relative
to the location of the executable binary. That is what this patch
does.
Differential Revision: https://reviews.llvm.org/D97786
DWARF allows .dwo file paths to be relative rather than absolute. When
they are relative, DWARF uses DW_AT_comp_dir to find the .dwo
file. DW_AT_comp_dir can also be relative, making the entire search
patch for the .dwo file relative. In this case, LLDB currently
searches relative to its current working directory, i.e. the directory
from which the debugger was launched. This is not right, as the
compiler, which generated the relative paths, can have no idea where
the debugger will be launched. The correct thing is to search relative
to the location of the executable binary. That is what this patch
does.
Differential Revision: https://reviews.llvm.org/D97786
This functionality is used exactly once, and it is trivial to implement
it differently (capture into two distinct variables, and compare for
equality afterwards).
By checking for cpu and toolchain features ahead
of time we don't need the custom return codes.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D97684
These two functions are doing the same thing, only one of them is
sending the packets immediately and the other "queues" them to be sent
later. The first one is better as in case of errors, the backtrace will
point straight to the place that caused them.
Modify the first method to avoid duplication, and ten standardize on it.
This test is flakey because it tries to read the proc/smaps
file of the first lldb-server process it finds. This process
can finish before we finish doing that.
http://lab.llvm.org:8011/#/builders/96/builds/6634/steps/6/logs/stdio
For now limit this to MTE targets which basically means
QEMU via lldb-dotest, which doesn't have this issue.
I'll fix the race condition shortly.
The annotation is now (since the introduction of @apple_simulator_test)
redundant, and the test could theoretically run on lldb-server too (if
it supported darwin hosts).
These tests fail if you build without the x86 llvm backend.
Either because they use an x86 triple or try to backtrace which
requires some x86 knowledge to see all frames.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D100194
The original commit was reverted because of the problems it introduced
on Linux. However, FreeBSD should not be affected, so restore that part
and we will address Linux separately.
While at it, remove the dbreg hack as the underlying issue has been
fixed in the FreeBSD kernel and the problem is unlikely to happen
in real life use anyway.
Differential Revision: https://reviews.llvm.org/D98822
This commit has caused the following tests to be flaky:
TestThreadSpecificBpPlusCondition.py
TestExitDuringExpression.py
The exact cause is not known yet, but since both tests deal with
threads, my guess is it has something to do with the tracking of
creation of new threads (which the commit touches upon).
This reverts the following commits:
d01bff8cbd,
ba62ebc48e,
e761b6b4c5,
a345419ee0.
The core file used is built for i386 so we
need the x86 backend to be able to load it.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D100195
Previously the test would fail if you built on Arm/AArch64
but did not have the x86 llvm backend enabled.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D100192
By moving them into a folder with a local lit config
requiring x86. All these tests use x86 target triples.
There are two tests that require target-x86_64 because
they run program files (instead of just needing the backend).
Those are moved to the x86 folder also but their REQUIRES are
unchanged.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D100193
Muhammad Omair Javaid