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
For example, it is pretty easy to write a breakpoint command that implements "stop when my caller is Foo", and
it is pretty easy to write a breakpoint command that implements "stop when my caller is Bar". But there's no
way to write a generic "stop when my caller is..." function, and then specify the caller when you add the
command to a breakpoint.
With this patch, you can pass this data in a SBStructuredData dictionary. That will get stored in
the PythonCommandBaton for the breakpoint, and passed to the implementation function (if it has the right
signature) when the breakpoint is hit. Then in lldb, you can say:
(lldb) break com add -F caller_is -k caller_name -v Foo
More generally this will allow us to write reusable Python breakpoint commands.
Differential Revision: https://reviews.llvm.org/D68671
Install llvm's signal handlers up front to prevent lldb's handlers from being
ignored. This is (hopefully) a stopgap workaround.
When lldb invokes an llvm API that installs signal handlers (e.g.
llvm::sys::RemoveFileOnSignal, possibly via a compiler embedded within lldb),
lldb's signal handlers are overriden if llvm is installing its handlers for the
first time.
To work around llvm's behavior, force it to install its handlers up front, and
*then* install lldb's handlers. In practice this is used to prevent lldb test
processes from exiting due to IO_ERR when SIGPIPE is received.
Note that when llvm installs its handlers, it 1) records the old handlers it
replaces and 2) re-installs the old handlers when its new handler is invoked.
That means that a signal not explicitly handled by lldb can fall back to being
handled by llvm's handler the first time it is received, and then by the
default handler the second time it is received.
Differential Revision: https://reviews.llvm.org/D69403
Summary:
This patch fixes a crash encountered when debugging optimized code. If some
variable has been completely optimized out, but it's value is nonetheless known,
the compiler can replace it with a DWARF expression computing its value. The
evaluating these expressions results in a eValueTypeHostAddress Value object, as
it's contents are computed into an lldb buffer. However, any value that is
obtained by dereferencing pointers in this object should no longer have the
"host" address type.
Lldb had code to account for this, but it was only present in the
ValueObjectVariable class. This wasn't enough when the object being described
was a struct, as then the object holding the actual pointer was a
ValueObjectChild. This caused lldb to dereference the contained pointer in the
context of the host process and crash.
Though I am not an expert on ValueObjects, it seems to me that this children
address type logic should apply to all types of objects (and indeed, applying
applying the same logic to ValueObjectChild fixes the crash). Therefore, I move
this code to the base class, and arrange it to be run everytime the value is
updated.
The test case is a reduced and simplified version of the original debug info
triggering the crash. Originally we were dealing with a local variable, but as
these require a running process to display, I changed it to use a global one
instead.
Reviewers: jingham, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D69273
Michał Górny