Add a 'can_connect' parameter to Process plugin initialization, and use
it to filter plugins to these capable of remote connections. This is
used to prevent 'process connect' from picking up a plugin that can only
be used locally, e.g. the legacy FreeBSD plugin.
Differential Revision: https://reviews.llvm.org/D91810
I think the check for whether the process is connected is totally bogus
in the first place, but on the off-chance that's it's not, we should
behave the same in synchronous and asynchronous mode.
This reverts commit f775fe5964.
I fixed a return type error in the original patch that was causing a test failure.
Also added a REQUIRES: python to the shell test so we'll skip this for
people who build lldb w/o Python.
Also added another test for the error printing.
This recommits f665e80c02 which was reverted in 1cbd1b8f69 for breaking
TestFoundationDisassembly.py. The fix is to use --force in the test to avoid
bailing out on large functions.
I have also doubled the large function limit to 8000 bytes (~~ 2000 insns), as
the foundation library contains a lot of large-ish functions. The intent of this
feature is to prevent accidental disassembling of enormous (multi-megabyte)
"functions", not to get in people's way.
The original commit message follows:
If we have a binary without symbol information (and without
LC_FUNCTION_STARTS, if on a mac), then we have to resort to using
heuristics to determine the function boundaries. However, these don't
always work, and so we can easily end up thinking we have functions
which are several megabytes in size. Attempting to (accidentally)
disassemble these can take a very long time spam the terminal with
thousands of lines of disassembly.
This patch works around that problem by adding a sanity check to the
disassemble command. If we are about to disassemble a function which is
larger than a certain threshold, we will refuse to disassemble such a
function unless the user explicitly specifies the number of instructions
to disassemble, uses start/stop addresses for disassembly, or passes the
(new) --force argument.
The threshold is currently fairly aggressive (4000 bytes ~~ 1000
instructions). If needed, we can increase it, or even make it
configurable.
Differential Revision: https://reviews.llvm.org/D79789
Summary:
If we have a binary without symbol information (and without
LC_FUNCTION_STARTS, if on a mac), then we have to resort to using
heuristics to determine the function boundaries. However, these don't
always work, and so we can easily end up thinking we have functions
which are several megabytes in size. Attempting to (accidentally)
disassemble these can take a very long time spam the terminal with
thousands of lines of disassembly.
This patch works around that problem by adding a sanity check to the
disassemble command. If we are about to disassemble a function which is
larger than a certain threshold, we will refuse to disassemble such a
function unless the user explicitly specifies the number of instructions
to disassemble, uses start/stop addresses for disassembly, or passes the
(new) --force argument.
The threshold is currently fairly aggressive (4000 bytes ~~ 1000
instructions). If needed, we can increase it, or even make it
configurable.
Differential Revision: https://reviews.llvm.org/D79789
We have the option to stop running commands in batch mode when an error
occurs. When that happens we should exit the driver with a non-zero exit
code.
Differential revision: https://reviews.llvm.org/D78825
The function consisted of a complicated set of conditions to compute the
address ranges which are to be disassembled (depending on the mode
selected by command line switches). This patch creates a separate
function for each mode, so that DoExecute is only left with the task of
figuring out how to dump the relevant ranges.
This is NFC-ish, except for one change in the error message, which is
actually an improvement.
This command had nearly identical code for the "then" and "else"
branches of the "if (m_options.num_instructions != 0)" condition.
This patch factors out the common parts of the two blocks to reduce
duplication.
While we have some tests for this command already, they are very vague.
This is not surprising -- it's hard to make strict assertions about the
assembly if your input is a c++ source file. This means that the tests
can more-or-less only detect when the command breaks completely, and not
when there is a subtle change in meaning due to e.g. a code refactor --
which is something that I am getting ready to do.
This tests in this patch create binaries with well known data (via assembler
and yaml2obj). This means that we are able to make precise assertions
about the text that lldb is supposed to print. As some of the features
of this command are only available with a real process, I use a minidump
core file to create a sufficiently realistic process object.
Summary:
If a command from a sourced file produces asynchronous output, this
output often does not make its way to the user. This happens because the
asynchronous output machinery relies on the iohandler stack to ensure
the output does not interfere with the things the iohandler is doing.
However, if this happens near the end of the command stream then by the
time the asynchronous output is produced we may already have already
started tearing down the sourcing session. Specifically, we may already
pop the relevant iohandler, leaving the stack empty.
This patch makes sure this kind of output gets printed by adding a
fallback to IOHandlerStack::PrintAsync to print the output directly if
the stack is empty. This is safe because if we have no iohandlers then
there is nothing to synchronize.
Reviewers: JDevlieghere, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D75454
We were incorrectly parsing the -C argument to breakpoint set as the
column breakpoint, even though according to the help this should be the
breakpoint command. This fixes that by renaming the option to -u, adding
it to help, and adding a test case.
Differential revision: https://reviews.llvm.org/D73284
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
LLDB has three major testing strategies: unit tests, tests that exercise
the SB API though dotest.py and what we currently call lit tests. The
later is rather confusing as we're now using lit as the driver for all
three types of tests. As most of this grew organically, the directory
structure in the LLDB repository doesn't really make this clear.
The 'lit' tests are part of the root and among these tests there's a
Unit and Suite folder for the unit and dotest-tests. This layout makes
it impossible to run just the lit tests.
This patch changes the directory layout to match the 3 testing
strategies, each with their own directory and their own configuration
file. This means there are now 3 directories under lit with 3
corresponding targets:
- API (check-lldb-api): Test exercising the SB API.
- Shell (check-lldb-shell): Test exercising command line utilities.
- Unit (check-lldb-unit): Unit tests.
Finally, there's still the `check-lldb` target that runs all three test
suites.
Finally, this also renames the lit folder to `test` to match the LLVM
repository layout.
Differential revision: https://reviews.llvm.org/D68606
llvm-svn: 374184
Michał Górny