The VSCode tests were all disabled on macOS because the implementation
had some issues that resulted in flakiness on Darwin. It seems most of
these issues have been addressed. I've re-enabled all the tests that
consistently passed locally.
Currently nothing prevents you from continuing your debug session after
generating the reproducer. This can cause the reproducer to end up in an
inconsistent state. Most of the time this doesn't matter, but I want to
prevent this from causing bugs in the future.
When we switched to the LLVM .debug_line parser, the .dSYM-style path
remapping logic stopped working for relative paths because of how
RemapSourceFile silently fails for relative paths. This patch both
makes the code more readable and fixes this particular bug.
One interesting thing I learned is that Module::RemapSourceFile() is a
macOS-only code path that operates on on the lldb::Module level and is
completely separate from target.source-map, which operates on a
per-Target level.
Differential Revision: https://reviews.llvm.org/D70037
rdar://problem/56924558
gcc-9 started warning when a class defined a copy constructor without a
copy assignment operator (or vice-versa).
This fixes those warnings by deleting the other special member too
(after verifying it doesn't do anything non-trivial).
The mock server pretends the process stopped with signal 17, which is
SIGCHLD on linux. This causes lldb to resume to process, utterly
confusing the test. Lldb probably shouldn't resume in this case, but for
now this issue can be fixed by changing the signal number to 2, which is
SIGINT just about anywhere.
until we can automatically fall back to p/P if g/G are not supported;
it looks like there is a bug in debugserver's g/G packets taht needs
to be fixed, or debugserver should stop supporting g/G until that bug
is fixed. But we need lldb to be able to fall back to p/P correctly
for that to be a viable workaround.
and that lldb uses the expedited register values in the ? packet
aka stop packet (T11 etc) and does not re-fetch them with the p packet.
This test is currently failing from the "[lldb-server] Add setting to
force 'g' packet use" commit; I'm marking it as @expectedFailureAll
until we can get this fixed.
The code that works around SIP was unintentionally being triggered for
/usr/local/bin/python as well. That caused trouble on GreenDragon where
we were swapping out a Python 3 executable with the system's Python 2
executable.
The function call and the constructor call fail now several Linux
bots (Swift CI, my own bot and Stella's Debian system), so let's disable
the relevant test parts until we can figure out why it is failing.
Summary:
All type in these functions need be valid and Clang types, so
we might as well replace these checks with IsClangType.
Also lets IsClangType explicitly check for validity instead of
assuming that the TypeSystem is a nullptr.
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70001
so we only call ModulesDidLoad at the end of the method
after the new module has been added to the target and
the sections have all been adjusted to their actual
load addresses. Solves a problem where an operating
system plugin in the kernel could be loaded multiple
times; the first before the binary had even been
added to the target.
<rdar://problem/50523558>
causing the -D option for breakpoint set command to be incorrectly parsed.
Patch by Martin Svensson.
Differential Revision: https://reviews.llvm.org/D69425
While investigating an issue where a different packet was sent during
replay I noticed how annoying it is that the existing assert doesn't
specify what packet is actually different. It's printed to the log, but
enabling logging has the potential to change LLDB's behavior. The same
is true when debugging LLDB while it's replaying the reproducer.
I replaced the assert with a printf of the unexpected packet followed by
a fatal_error wrapped in ifndef NDEBUG. The behavior is the same as the
previous assert, just with more/better context.
This is yet another change to the regular expressions in crashlog.py
that fix a few edge cases, and attempt to improve the readability
quite a bit in the process. My last change to support spaces in
filenames introduced a bug that caused the version/archspec field to
be parsed as part of the image name.
For example, in "0x1111111 - 0x22222 +MyApp Pro arm64 <01234>", the
name of the image was recognized as "MyApp Pro arm64" instead of
"MyApp Pro" with a "version" of arm64.
The bugfix makes the space following an optional field mandatory
*inside* the optional group.
rdar://problem/56883435
Differential Revision: https://reviews.llvm.org/D69871
Summary: This option was added downstream in swift-lldb. This upstreams this option as it seems useful and also adds the missing tests.
Reviewers: #lldb, kwk, labath
Reviewed By: kwk, labath
Subscribers: labath, kwk, abidh, JDevlieghere, lldb-commits
Tags: #lldb, #upstreaming_lldb_s_downstream_patches
Differential Revision: https://reviews.llvm.org/D69944
Following up on https://reviews.llvm.org/D62221, this change introduces
the settings plugin.process.gdb-remote.use-g-packet-for-reading. When
they are on, 'g' packets are used for reading registers.
Using 'g' packets can improve performance by reducing the number of
packets exchanged between client and server when a large number of
registers needs to be fetched.
Differential revision: https://reviews.llvm.org/D62931
Performance issues lead to the libc++ std::function formatter to be disabled.
This change is the first of two changes that should address the performance issues and allow us to enable the formatter again.
In some cases we end up scanning the symbol table for the callable wrapped by std::function for those cases we will now cache the results and used the cache in subsequent look-ups. This still leaves a large cost for the initial lookup which will be addressed in the next change.
Differential Revision: https://reviews.llvm.org/D67111
To do so, we need to register the sanitizer libraries with the target
so that they get uploaded before running. This patch adds a helper to
the test class to this effect.
If you are running on macOS and have the CommandLineTools installed of
Xcode, this test will fail because CommandLineTools doesn't ship with
libMainThreadChecker. Skip the test if you don't have it installed.
Summary: Similar to D68370 but for darwin framework build.
Reviewers: aadsm
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69834
This is a non-Swift-specific change in swift-lldb that seems to be
useful for remote debugging. If does in fact turn out to be redundant
we can remove it from llvm.org and then it will disappear in
swift-lldb, too.
Restrict building the readline override to Linux only. It both does not
build on *BSD systems, and is largely irrelevant since they default to
using libedit over readline anyway. This restores the behavior
of the old readline override that also was built only on Linux.
Differential Revision: https://reviews.llvm.org/D69846
Jonas Devlieghere