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
Fix https://bugs.llvm.org/show_bug.cgi?id=43830 while avoiding polluting the
global Python namespace.
This both reverts r357277 to rebundle a version of Python's readline module
based on libedit.
However, this patch also provides two improvements over the previous
implementation:
1. use PyMem_RawMalloc instead of PyMem_Malloc, as expected by PyOS_Readline
(prevents to segfault upon exit of interactive session)
2. patch the readline module upon embedded interpreter loading, instead of
patching it globally, which should prevent any side effect on other
modules/packages
3. only activate the patched module if libedit is actually linked in lldb
Differential Revision: https://reviews.llvm.org/D69793
Summary:
The permissions in a memory region have ternary states (yes, no, don't
know), but the memory region command only prints in binary, treating
"don't know" as "yes", which is particularly confusing as for instance
the unwinder will treat an unknown value as "no".
This patch makes is so that we distinguish all three states when
printing the values, using "?" to indicate the lack of information. It
is implemented via a special argument to the format provider for the
OptionalBool enumeration.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D69106
The swift build system has support for cross-compiling, installing, and
generating symbols for lldb. As the swift symbol-generation step occurs
after installation, we need to disable stripping during the install.
Summary:
This patch updates the last user of ArgInfo::count and deletes
it. I also delete `GetNumInitArguments()` and `GetInitArgInfo()`.
Classess are callables and `GetArgInfo()` should work on them.
On python 3 it already works, of course. `inspect` is good.
On python 2 we have to add yet another special case. But hey if
python 2 wasn't crufty we wouln't need python 3.
I also delete `is_bound_method` becuase it is unused.
This path is tested in `TestStepScripted.py`
Reviewers: labath, mgorny, JDevlieghere
Reviewed By: labath, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69742
Add info for all register sets supported in NetBSD, particularly for all
registers 'expected' by LLDB. This is necessary in order to fix
python_api/lldbutil/iter/TestRegistersIterator.py test that currently
fails due to missing names of register sets (None).
This copies fpreg descriptions from Linux, and combines Linux' AVX
and MPX registers into a single XState group, to fit NetBSD register
group design. Technically, we do not support MPX registers
at the moment but gdb-remote insists on passing their errors anyway,
and if we do not include it in any group, they end up in a separate
anonymous group that breaks the test.
While at it, swap the enums for XState and DBRegs to match register set
ordering.
This also adds a few consts to the lldb-x86-register-enums.h to provide
more consistency between user registers and debug registers.
Differential Revision: https://reviews.llvm.org/D69667
Summary:
This function is only used internally by ClangExpressionParser. By putting it in the ExpressionParser class all languages
that implement ExpressionParser::Parse have to share the same signature (which forces us in downstream to add
swift-specific arguments to ExpressionParser::Parse which then propagate to ClangExpressionParser and so on).
Reviewers: davide
Subscribers: JDevlieghere, lldb-commits
Tags: #upstreaming_lldb_s_downstream_patches, #lldb
Differential Revision: https://reviews.llvm.org/D69710
Summary:
I don't see why this test needs to compile this rather complicated file for just testing module sections. This just removes all this code with a simple
"Hello world!" program which should be faster to compile
Reviewers: labath, davide, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69705
Summary:
We disabled registration by providing an empty `registerEHFrames`, so we should also provide an empty `deregisterEHFrames`
in case that function relies on `registerEHFrames` being called before. Currently `deregisterEHFrames` is a no-op anyway
as it just iterates over the (empty( list of registered EHFrames and then clear the empty list.
Reviewers: davide, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere, lldb-commits
Tags: #upstreaming_lldb_s_downstream_patches, #lldb
Differential Revision: https://reviews.llvm.org/D69713
Summary:
Motivated by Swift using the materializer in a few places which requires us to add this getter ourselves.
We also need a setter, but let's keep this minimal to unblock the downstream reverts in Swift.
Reviewers: davide
Reviewed By: davide
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #upstreaming_lldb_s_downstream_patches, #lldb
Differential Revision: https://reviews.llvm.org/D69714
Normally you shouldn't be able to have a process with an ItaniumABI plugin
that doesn't have this symbol. But if the loader crashes before loading
libc++abi.dylib (on MacOS), then the symbol might not be present. So we
should check before accessing the pointer.
There isn't a good way to write a test for this, but the change is obvious.
This allows explicitly specifying the intended target architecture,
for tests that aren't supposed to be executed, and that don't
require MSVC headers or libraries to be available.
(These tests already implicitly assumed to be built for x86; one
didn't specify anything, assuming x86_64, while the other specified
--arch=32, which only picks the 32 bit variant of the default target
architecture).
Join two comment lines in disassembly.cpp, to keep row numbers
checked in the test unchanged.
This fixes running check-lldb on arm linux.
Previously when this was applied (in 95980409e6), it broke
macos buildbots, as they added "-isysroot <path>" to all %clang*
substitutions, and clang-cl didn't support that.
Reapplying it without further changes to this patch, after D69619
(9c73925226), because now, such extra parameters are added to
%clang_host*, but not to plain %clang_cl.
Differential Revision: https://reviews.llvm.org/D69031
Summary:
Instead of filling out a std::string and returning a bool to indicate
success, returning a std::string directly and testing to see if it's
empty seems like a cleaner solution overall.
Differential Revision: https://reviews.llvm.org/D69641
Summary:
Not all minidumps contain information about memory permissions. However,
it is still important to know which regions of memory contain
potentially executable code. This is particularly important for
unwinding on win32, as the default unwind method there relies on
scanning the stack for things which "look like" code pointers.
This patch enables ProcessMinidump to reconstruct the likely permissions
of memory regions using the sections of loaded object files. It only
does this if we don't have a better source (memory info list stream, or
linux /proc/maps) for this information, and only if the information in
the object files does not conflict with the information in the minidump.
Theoretically that last bit could be improved, since the permissions
obtained from the MemoryList streams is also only a very rough guess,
but it did not seem worthwhile to complicate the implementation because
of that because there will generally be no overlap in practice as the
MemoryList will contain the stack contents and not any module data.
The patch adds a test checking that the module section permissions are
entered into the memory region list, and also a test which demonstrate
that now the unwinder is able to correctly find return addresses even in
minidumps without memory info list streams.
There's one TODO left in this patch, which is that the "memory region"
output does not give any indication about the "don't know" values of
memory region permissions (it just prints them as if they permission bit
was set). I address this in a follow up.
Reviewers: amccarth, clayborg
Subscribers: mgrang, lldb-commits
Differential Revision: https://reviews.llvm.org/D69105
Summary:
This change increases the offset of MPX registers (by 128) so they
do not overlap with the offset associated with AVX registers. That was
causing MPX data in GDBRemoteRegisterContext::m_reg_data to get overwritten.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68874
Summary:
This patch addresses an ambiguity in how our existing tests invoke the
compiler. Roughly two thirds of our current "shell" tests invoke the
compiler to build the executables for the host. However, there is also
a significant number of tests which don't build a host binary (because
they don't need to run it) and instead they hardcode a certain target.
We also have code which adds a bunch of default arguments to the %clang
substitutions. However, most of these arguments only really make sense
for the host compilation. So far, this has worked mostly ok, because the
arguments we were adding were not conflicting with the target-hardcoding
tests (though they did provoke an occasional "argument unused" warning).
However, this started to break down when we wanted to use
target-hardcoding clang-cl tests (D69031) because clang-cl has a
substantially different command line, and it was getting very confused
by some of the arguments we were adding on non-windows hosts.
This patch avoid this problem by creating separate %clang(xx,_cl)_host
substutitions, which are specifically meant to be used for compiling
host binaries. All funny host-specific options are moved there. To
ensure that the regular %clang substitutions are not used for compiling
host binaries (skipping the extra arguments) I employ a little
hac^H^H^Htrick -- I add an invalid --target argument to the %clang
substitution, which means that one has to use an explicit --target in
order for the compilation to succeed.
Reviewers: JDevlieghere, aprantl, mstorsjo, espindola
Subscribers: emaste, arichardson, MaskRay, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69619
This can e.g. happen if the debugged executable exits before the initial
stop, e.g. if it fails to load dependent DLLs.
Add a virtual destructor to ProcessDebugger and let it clean up the
session, and make ProcessWindows::OnExitProcess call
ProcessDebugger::OnExitProcess for shared parts.
Fix suggestion by Adrian McCarthy.
Differential Revision: https://reviews.llvm.org/D69503
llvm::object::createBinary returns an Expected<>, which requires
not only checking the object for success, but also requires consuming
the Error, if one was set.
Use LLDB_LOG_ERROR for this case, and change an existing similar log
statement to use it as well, to make sure the Error is consumed even
if the log channel is disabled.
Differential Revision: https://reviews.llvm.org/D69646
Contrary to WoW64 on x86_64, there's no struct similar to WOW64_CONTEXT
defined, for storing and handling the CPU state of an ARM32 process
from an ARM64 process. Thus, making an ARM64 lldb-server able to
control ARM32 processes seems infeasible at the moment.
(The normal CONTEXT struct has a different layout on each architecture.
In addition to this, a WOW64_CONTEXT struct always is defined, that
can store the CPU state of an x86_32 process, to allow handling it from
an x86_64 process. But there's no similar universally available struct
for ARM32.)
When building standalone, `LLVM_DEFAULT_TARGET_TRIPLE` may be undefined.
Matching against an empty string does not work as desired in CMake, so,
fallback to the old behaviour, defaulting `LLDB_DEBUGSERVER_ARCH` to
`CMAKE_OSX_ARCHITECTURES`.
This is a quick followup to this commit:
https://reviews.llvm.org/rGa69bbe02a2352271e8b14542073f177e24c499c1
In that, I #pragma-squelch this warning in `ScriptInterpreterPython.cpp`
but we get the same warning in `PythonTestSuite.cpp`.
This patch squelches the same warning in the same way as the
reviweed commit. I'm submitting it without review under the
"obviously correct" rule.
At least if this is incorrect the main commit was also incorrect.
By the way, as far as I can tell, these functions are extern "C" because
SWIG does that to everything, not because they particularly need to be.
Summary:
It is inherently unsafe to allow a python program to manipulate borrowed
memory from a python object's destructor. It would be nice to
flush a borrowed file when python is finished with it, but it's not safe
to do on python 2.
Python 3 does not suffer from this issue.
Reviewers: labath, mgorny
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69532
The architecture enum contains two kinds of contstants: the "official" ones
defined by Microsoft, and unofficial constants added by breakpad to cover the
architectures not described by the first ones.
Up until now, there was no big need to differentiate between the two. However,
now that Microsoft has defined
https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info
a constant for ARM64, we have a name clash.
This patch renames all breakpad-defined constants with to include the prefix
"BP_". This frees up the name "ARM64", which I'll re-introduce with the new
"official" value in a follow-up patch.
Reviewers: amccarth, clayborg
Subscribers: lldb-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D69285
Summary: _setmode in assert will not run when build with NDEBUG
Reviewers: mstorsjo, labath, amccarth
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69612
Summary:
This enables us to reason about whether a given address can be
executable, for instance during unwinding.
Reviewers: amccarth, mstorsjo
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D69102
Summary:
Move breakpoints from the old, bad ArgInfo::count to the new, better
ArgInfo::max_positional_args. Soon ArgInfo::count will be no more.
It looks like this functionality is already well tested by
`TestBreakpointCommandsFromPython.py`, so there's no need to write
additional tests for it.
Reviewers: labath, jingham, JDevlieghere
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69468
Summary:
Here's another instance where we were calling fflush on an input
stream, which is illegal on NetBSD.
Reviewers: labath, mgorny
Reviewed By: mgorny
Subscribers: krytarowski, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69488
Apple's greendragon bot uses a standalone build of lldb which would
fail to build after a recent change to LLVM as it relied on LLVM setting
global flags for its build. Attempt to repair the standalone build for
greendragon bot.
`LLVM_DEFAULT_TARGET_TRIPLE` is a cached variable, which means that it
may actually be unset. Furthermore, in standalone builds, the variable
may be fully undefined. Apply the regular expression over the empty
string in such a case. This should improve the state of the green
dragon bot.
The virtual container/header section caused the section list to be
offset by one, but by using FindSectionByID, the layout of the
section list shouldn't matter.
Differential Revision: https://reviews.llvm.org/D69366
Summary: This is the last part. And we can remove the python script.
Subscribers: lldb-commits, mgorny
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69019
This test was timing out on the swift CI bots. I didn't see any obvious reason
for that, and the test hasn't had problems on greendragon. OTOH, it was a bit
oddly written, and needed modernizing, so I did that.
Differential Revision: https://reviews.llvm.org/D69453
The debugserver build needs to conditionally include files depending on the
target architecture.
Switch on the architecture specified by LLVM_DEFAULT_TARGET_TRIPLE, as
the llvm and swift build systems use this variable to identify the
target (the latter, indirectly, through LLVM_HOST_TRIPLE).
It would be possible to switch on CMAKE_OSX_ARCHITECTURES, but the swift
build does not provide it, preferring instead to pass arch-specific
CFLAGS etc explicitly. Switching on LLVM_HOST_TRIPLE is also an option,
but it breaks down when cross-compiling.
Differential Revision: https://reviews.llvm.org/D69523
The page describing how to get the sources was more about contributing
to LLDB than getting the actual source. This patch moves some things
around and repurposes this page as a contributing to LLDB landing page.
Summary:
We add support for DW_AT_export_symbols to detect anonymous struct on top of the heuristics implemented in D66175
This should allow us to differentiate anonymous structs and unnamed structs.
We also fix TestTypeList.py which was incorrectly detecting an unnamed struct as an anonymous struct.
Differential Revision: https://reviews.llvm.org/D68961
The invocation shown by dotest.py to re-run a single test is misleading:
it ranges from missing arguments (best case scenario) to being totally
wrong (worst case scenario).
In the past I've tried to get it right, but given the dotest
architecture this is harder than it looks. Furthermore, we have pretty
good documentation on the website [1] for most use cases.
This patch removes the rerun invocation.
[1] https://lldb.llvm.org/resources/test.html
This leads to a configuration error because we're trying to get a
property that doesn't exist:
get_target_property() called with non-existent target "swig_wrapper"
Summary:
Move breakpoints from the old, bad ArgInfo::count to the new, better
ArgInfo::max_positional_args. Soon ArgInfo::count will be no more.
This functionality is tested in `TestFormatters.py`, `TestDataFormatterSynthVal.py`,
`TestDataFormatterSynthType.py`.
You may notice that the old code was passing 0 arguments when count was 1, and passing
1 argument when count is 2.
This is no longer necessary because max_positional_args counts the self pointer
correctly.
Reviewers: labath, jingham, JDevlieghere
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69469
This prevents unused variable warning/error in -DNDEBUG builds. The
variable was introduced in 5934cd11ea.
Patch by: Shu-Chun Weng
Differential revision: https://reviews.llvm.org/D69451
The goal of this refactor is to enable ProcessMinidump to take into
account the loaded modules and their sections when computing the
permissions of various ranges of memory, as discussed in D66638.
This patch moves some of the responsibility for computing the ranges
from MinidumpParser into ProcessMinidump. MinidumpParser still does the
parsing, but ProcessMinidump becomes responsible for answering the
actual queries about memory ranges. This will enable it (in a follow-up
patch) to augment the information obtained from the parser with data
obtained from actual object files.
The changes in the actual code are fairly straight-forward and just
involve moving code around. MinidumpParser::GetMemoryRegions is renamed
to BuildMemoryRegions to emphasize that it does no caching. The only new
thing is the additional bool flag returned from this function. This
indicates whether the returned regions describe all memory mapped into
the target process. Data obtained from /proc/maps and the MemoryInfoList
stream is considered to be exhaustive. Data obtained from Memory(64)List
is not. This will be used to determine whether we need to augment the
data or not.
This reshuffle means that it is no longer possible/easy to test some of
this code via unit tests, as constructing a ProcessMinidump instance is
hard. Instead, I update the unit tests to only test the parsing of the
actual data, and test the answering of queries through a lit test using
the "memory region" command. The patch also includes some tweaks to the
MemoryRegion class to make the unit tests easier to write.
Reviewers: amccarth, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D69035
In an attempt to ensure that every part of the module's memory image is
accounted for, D56537 created a special "container section" spanning the
entire image. While that seemed reasonable at the time (and it still
mostly does), it did create a problem of what to put as the "file size"
of the section, because the image is not continuous on disk, as we
generally assume (which is why I put zero there). Additionally, this
arrangement makes it unclear what kind of permissions should be assigned
to that section (which is what my next patch does).
To get around these, this patch partially reverts D56537, and goes back
to top-level sections. Instead, what I do is create a new "section" for
the object file header, which is also being loaded into memory, though
its not considered to be a section in the strictest sense. This makes it
possible to correctly assign file size section, and we can later assign
permissions to it as well.
Reviewers: amccarth, mstorsjo
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D69100
Jonas Devlieghere