| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DWARF5 line tables
Summary:
Lldb's "format-independent" debug info made use of the fact that DWARF
(<=4) did not use the file index zero, and reused the support file index
zero for storing the compile unit name.
While this provided some convenience for DWARF<=4, it meant that the PDB
plugin needed to artificially remap file indices in order to free up
index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that
similar remapping would be needed in the dwarf plugin too.
What this patch does instead is remove the requirement of having the
compile unit name in the index 0. It is not that useful since the name
can always be fetched from the CompileUnit object. Remapping code in the
pdb plugin(s) has been removed or simplified.
DWARF plugin has started inserting an empty FileSpec at index 0 to
ensure the indices keep matching up (in case of DWARF<=4). For DWARF5,
we insert the file 0 from the line table.
I add a test to ensure we can correctly lookup line table entries
referencing file 0, and in particular the case where the file 0 is also
duplicated in another file entry, as this is how clang produces line
tables in some circumstances (see pr44170). Though this is probably a
bug in clang, this is not forbidden by DWARF, and lldb already has
support for that in some (but not all) cases -- this adds a test for the
code path which was not fixed in this patch.
Reviewers: clayborg, JDevlieghere, jdoerfert
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70954
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make it possible to override reproducer capture with the
LLDB_CAPTURE_REPRODUCER environment variable.
The goal of this change is twofold.
(1) I want to be able to enable capturing reproducers during regular
test runs, both locally and on the bots. To do so I need a way to
force capture. I cannot do this through the Python API, because
reproducer capture must be enabled *before* the debugger
initialized, which happens automatically when doing `import lldb`.
(2) I want to provide an escape hatch for when reproducers are enabled
by default. Downstream we have reproducer capture enabled by default
in the driver.
This patch solves both problems by overriding the reproducer mode based
on the environment variable. Acceptable values are 0/1 and ON/OFF.
|
|
|
|
|
|
|
|
|
| |
The previous fix attempt, in 62a635e864e0, used too much escaping
for the backslashes.
But instead of using regexes to match both path separator forms,
remove the path altogether to unify the output from the testcase
between platforms.
|
|
|
|
| |
Remove things irrelevant to the test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To ensure a reproducer works correctly, the version of LLDB used for
capture and replay must match. Right now the reproducer already contains
the LLDB version. However, this is purely informative. LLDB will happily
replay a reproducer generated with a different version of LLDB, which
can cause subtle differences.
This patch adds a version check which compares the current LLDB version
with the one in the reproducer. If the version doesn't match, LLDB will
refuse to replay. It also adds an escape hatch to make it possible to
still replay the reproducer without having to mess with the recorded
version. This might prove useful when you know two versions of LLDB
match, even though the version string doesn't. This behavior is
triggered by passing a new flag -reproducer-skip-version-check to the
lldb driver.
Differential revision: https://reviews.llvm.org/D70934
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If filling in a DataExtractor from an ObjectFile, e.g. via the
ReadSectionData method, the output DataExtractor gets the address
size from the m_data member.
ObjectFile's m_data member is initialized without knowledge about
the address size (so the address size is set based on the host's
sizeof(void*), and at that point within ObjectFile's constructor,
virtual methods implemented in subclasses (like GetAddressByteSize())
can't be called, therefore fix it up when filling in external
DataExtractors.
This makes sure that line tables from executables with a different
address size are parsed properly; previously this tripped up
DWARFDebugLine::LineTable::parse for 32 bit executables on a 64 bit
host, as the address size in the line table (4) didn't match the
one set in the DWARFDataExtractor.
Differential Revision: https://reviews.llvm.org/D70848
|
|
|
|
|
|
|
| |
Extend EmulateMOVRdRm to identify "mov r11, sp" in thumb mode as
setting the frame pointer, if r11 is the frame pointer register.
Differential Revision: https://reviews.llvm.org/D70797
|
| |
|
|
|
|
|
|
|
|
| |
Windows on ARM always uses thumb mode, and doesn't have most of the
mechanisms that are used in e.g. ELF for distinguishing between arm
and thumb.
Differential Revision: https://reviews.llvm.org/D70796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
COFF section names can either be stored truncated to 8 chars, in the
section header, or as a longer section name, stored separately in the
string table.
libunwind locates the .eh_frame section by runtime introspection,
which only works for section names stored in the section header (as
the string table isn't mapped at runtime). To support this behaviour,
lld always truncates the section names for sections that will be
mapped, like .eh_frame.
Differential Revision: https://reviews.llvm.org/D70745
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I recently re-discovered that the unsinged stream operators of the
lldb_private::Stream class have a surprising behavior in that they print
the number in hex. This is all the more confusing because the "signed"
versions of those operators behave normally.
Now that, thanks to Raphael, each Stream class has a llvm::raw_ostream
wrapper, I think we should delete most of our formatting capabilities
and just delegate to that. This patch tests the water by just deleting
the operators with the most surprising behavior.
Most of the code using these operators was printing user_id_t values. It
wasn't fully consistent about prefixing them with "0x", but I've tried
to consistenly print it without that prefix, to make it more obviously
different from pointer values.
Reviewers: teemperor, JDevlieghere, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70241
|
|
|
|
| |
Include the fancier DWARF5 sections too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NetBSD ptrace interface does not populate watchpoints to newly-created
threads. Solve this via copying the watchpoints from the current thread
when new thread is reported via TRAP_LWP.
Add a test that verifies that when the user does not have permissions
to set watchpoints on NetBSD, the 'watchpoint set' errors out gracefully
and thread monitoring does not crash on being unable to copy watchpoints
to new threads.
Differential Revision: https://reviews.llvm.org/D70023
|
|
|
|
|
|
|
|
|
|
| |
This is a correctness fix for the Clang DWARF parser that primarily
matters for swift-lldb's ability to import Clang types that were
reconstructed from DWARF into Swift.
rdar://problem/55025799
Differential Revision: https://reviews.llvm.org/D70580
|
| |
|
|
|
|
| |
SIGBUS is not part of the signal macros defined in the header <csignal>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch hooks the reproducer infrastructure with the signal handlers.
When lldb crashes with reproducers capture enabled, it will now generate
the reproducer and print a short message the standard out. This doesn't
affect the pretty stack traces, which are still printed before.
This patch also introduces a new reproducer sub-command that
intentionally raises a given signal to test the reproducer signal
handling.
Currently the signal handler is doing too much work. Instead of copying
over files into the reproducers in the signal handler, we should
re-invoke ourselves with a special command line flag that looks at the
VFS mapping and performs the copy.
This is a NO-OP when reproducers are disabled.
Differential revision: https://reviews.llvm.org/D70474
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason the reproducer tests seem really proficient at
uncovering structural issues in LLDB related to how we tear down things,
but of course only on the bots.
The pretty stack trace helps a bit, but what I really want is the crash
reports which contain much more information, such as what other threads
we doing.
Crash reports are automatically suppressed by lit. This patch
(temporarily) disables that for the reproducer tests.
|
|
|
|
|
| |
If lldb was run in capture mode, but no reproducer was generated, make
sure we clean up the reproducer directory.
|
|
|
|
|
|
| |
Centralize the logic to remove debugserver from
LLVM_DISTRIBUTION_COMPONENTS when LLDB_USE_SYSTEM_DEBUGSERVER is
enabled. Now this happens regardless of whether the tests are enabled.
|
|
|
|
|
|
|
|
| |
This reverts commit 3f594ed1686b44138bee245c708773e526643aaf.
This change has cause LLDB expression evaluation to fail on Arm Linux.
Differential Revision: https://reviews.llvm.org/D63540
|
|
|
|
|
| |
Make the check generic instead of hard-coding the path to Python 2. This
also fixes the print-syntax to be compatible with both versions.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
g_breakpoint_dummy_options
causing the -D option for breakpoint set command to be incorrectly parsed.
Patch by Martin Svensson.
Differential Revision: https://reviews.llvm.org/D69425
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Without asan and tsan as test dependencies, you might end up with a
clang that points to sanitizer runtime library that hasn't been build
yet.
|
|
|
|
| |
This avoids config time dependencies on liblldb. And enables other refactoring.
|
|
|
|
| |
It's flaky.
|
| |
|
|
|
|
|
| |
This code path is only taken on the sanitized bot, where it caused a
TypeError: "Can't mix strings and bytes in path components".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
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 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lifetime
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
errors out on
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
|
|
|
|
|
|
| |
This can happen e.g. when unwinding doesn't work perfectly.
Differential Revision: https://reviews.llvm.org/D69502
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
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
|
|
|
|
|
| |
All *BSD targets do not implement ShellExpandArguments, so mark
the test appropriately.
|
| |
|
|
|
|
|
|
|
|
| |
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:
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 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
|