Summary:
If we build LLDB.framework, dependant tools need appropriate RPATHs in both locations, the build-tree (for testing) and the install-tree (for deployment). Luckily, CMake can handle it for us: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling.
* In the build-tree, tools use the absolute path to the framework's actual output location.
* In the install-tree, tools get a list of RPATHs to look for the framework when deployed.
`LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change the relative location of LLDB.framework in the install-tree.
If it is not empty, it will be added as an additional RPATH to all dependant tools (so they are functional in the install-tree).
If it is empty, LLDB.framework goes to the root and tools will not be functional in the directory structure of the LLVM install-tree.
For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to "Library/Frameworks".
Reviewers: xiaobai, JDevlieghere, aprantl, clayborg
Reviewed By: JDevlieghere
Subscribers: ki.stfu, mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55330
llvm-svn: 350392
Summary:
Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements.
Options:
* `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree)
* `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree
* `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`)
* `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets)
Other changes:
* clean up `add_lldb_executable()`
* include `LLDBFramework.cmake` from `source/API/CMakeLists.txt`
* use `*.plist.in` files, which are typical for CMake and independent from Xcode
* add clang headers to the framework bundle
Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath
Reviewed By: aprantl
Subscribers: friss, mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55328
llvm-svn: 350391
Summary:
One place for debugserver options, analog to LLDBConfig for LLDB options (see D55317). It was discussed in earlier reviews already, e.g. D55013.
Reviewers: JDevlieghere, aprantl, xiaobai
Reviewed By: aprantl, xiaobai
Subscribers: mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55320
llvm-svn: 350390
Summary:
Major fixes after D54476 (use Diff1 as base for comparison to see only recent changes):
* In standalone builds target directory for debugserver must be LLDB's bin, not LLVM's bin
* Default identity for code signing must not force-override LLVM_CODESIGNING_IDENTITY globally
We have a lot of cases, make them explicit:
* ID used for code signing (debugserver and in tests):
** `LLDB_CODESIGN_IDENTITY` if set explicitly, or otherwise
** `LLVM_CODESIGNING_IDENTITY` if set explicitly, or otherwise
** `lldb_codesign` as the default
* On Darwin we have a debugserver target that:
* On other systems, the debugserver target is not defined, which is equivalent to **[3A]**
Common configurations on Darwin:
* **[1A]** `cmake -GNinja ../llvm` builds debugserver from source and signs with `lldb_codesign`, no code signing for other binaries (prints status: //lldb debugserver: /path/to/bin/debugserver//)
* **[1A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_CODESIGN_IDENTITY=lldb_codesign ../llvm` builds debugserver from source and signs with `lldb_codesign`, ad-hoc code signing for other binaries (prints status: //lldb debugserver: /path/to/bin/debugserver//)
* **[2A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_USE_SYSTEM_DEBUGSERVER=ON ../llvm` copies debugserver from system, ad-hoc code signing for other binaries (prints status: //Copy system debugserver from: /path/to/system/debugserver//)
* **[2B]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- ../llvm` same, but prints additional warning: //Cannot code sign debugserver with identity '-'. Will fall back to system's debugserver. Pass -DLLDB_CODESIGN_IDENTITY=lldb_codesign to override the LLVM value for debugserver.//
* **[3A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_NO_DEBUGSERVER=ON ../llvm` debugserver not available (prints status: //lldb debugserver will not be available)//
Reviewers: JDevlieghere, beanz, davide, vsk, aprantl, labath
Reviewed By: JDevlieghere, labath
Subscribers: mgorny, #lldb, lldb-commits
Differential Revision: https://reviews.llvm.org/D55013
llvm-svn: 350388
Summary:
The implementation in CalculateSymbolSizes has been made redundant in
D19004, as this patch added another copy of size computation code into
InitAddressIndexes (which is called by CalculateSymbolSizes).
Reviewers: clayborg, jasonmolenda, tberghammer
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56132
llvm-svn: 350384
Summary:
The main difference between the classes was supposed to be the fact that
one is backed by llvm::SmallVector, and the other by std::vector.
However, over the years, they have accumulated various other differences
too.
This essentially removes the std::vector version, as that is pretty much
identical to llvm::SmallVector<T, 0>, and combines their interfaces. It
does not attempt to do a more significant refactoring, even though there
is still a lot of duplication in this file, as it is hard to tell which
quirk of some API is depended on by somebody (and, a previous, more
ambitious attempt at this in D16769 has failed).
I also add some tests, including one which demonstrates one of the
quirks/bugs of the API I have noticed in the process.
Reviewers: clayborg, teemperor, tberghammer
Subscribers: mgorny, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56170
llvm-svn: 350380
There is already in use:
lit/lit-lldb-init:
settings set symbols.enable-external-lookup false
packages/Python/lldbsuite/test/lldbtest.py:
self.runCmd('settings set symbols.enable-external-lookup false')
But those are not in effect during MI part of the testsuite. Another problem is
that symbols.enable-external-lookup (read by GetEnableExternalLookup) has been
currently read only by LocateMacOSXFilesUsingDebugSymbols and therefore it had
no effect on Linux.
On Red Hat platforms (Fedoras, RHEL-7) there is DWZ in use and so
MiSyntaxTestCase-test_lldbmi_output_grammar FAILs due to:
AssertionError: error: inconsistent pattern ''^.+?\n'' for state 0x5f
(matched string: warning: (x86_64) /lib64/libstdc++.so.6 unsupported
DW_FORM values: 0x1f20 0x1f21
It is the only testcase with this error. It happens due to:
(lldb) target create "/lib64/libstdc++.so.6"
Current executable set to '/lib64/libstdc++.so.6' (x86_64).
(lldb) b main
warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
which happens only with gcc-base-debuginfo rpm installed (similarly for other packages).
It should also speed up the testsuite as it no longer needs to read
/usr/lib/debug symbols which have no effect (and should not have any effect) on
the testsuite results.
Differential Revision: https://reviews.llvm.org/D55859
llvm-svn: 350368
Summary:
instead of returning the architecture through by-ref argument and a
boolean value indicating success, we can just return the ArchSpec
directly. Since the ArchSpec already has an invalid state, it can be
used to denote the failure without the additional bool.
Reviewers: clayborg, zturner, espindola
Subscribers: emaste, arichardson, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56129
llvm-svn: 350291
This is an alternate patch for the bug reported in
https://bugs.llvm.org/show_bug.cgi?id=39816 ("lldb doesn't show a file
of line entry for big project"). This limits the number of lines in a
source file to 32M, which I think is reasonable even for preprocessed
source inputs.
Differential Revision: https://reviews.llvm.org/D56218
llvm-svn: 350274
TestQueues is failing randomly on green dragon and I suspect it is
because the enqueued threads haven't executed by the time we expect
them. This patch adds file-based synchronization to the queues.
Differential Revision: https://reviews.llvm.org/D56208
llvm-svn: 350247
This is a first step towards getting lldb-test symbols working
with the native plugin. There is a remaining issue, which is
that the plugin expects that ParseDeclsForContext will also
create lldb symbols rather than just the decls, but the native
pdb plugin doesn't currently do this. This will be addressed
in a followup patch.
llvm-svn: 350243
A Previous patch added support for creating VarDecls for global
variables. This patch updates this test to be more strict and
actually check these, not just the types.
llvm-svn: 350242
There were several problems preventing this from working. The
first is that when the PDB had an absolute path to the main
source file, we would construct an invalid path by prepending the
compilation directory to it anyway. So we needed to check if the
path is already absolute first.
Second, LLDB assumes that the zero'th item in the support file list
is the main compilation unit. We were respecting this requirement,
but LLDB *also* requires that file to appear somewhere in the list
starting from index 1 as well. So the main compilation file should
appear in the support file list twice. And when parsing a line
table, it expects the LineEntry records to be constructed using
the 1-based index. With these two fixes we can now set breakpoints
by file and line using the native PDB reader.
llvm-svn: 350240
The warning comes from the fact that the MOCK_METHOD macros don't use the
override keyword internally. This makes us not use it in the manually overriden
methods either, to be consistent.
llvm-svn: 350209
Simplify some code in PreprocessCommand. This change improves
consistency, reduces the indentation and makes the code easier to follow
overall.
llvm-svn: 350166
python 3.7 removes re._pattern_type. Fix the one place where we were
depending on the type of regular expressions to compute the type
dynamically.
llvm-svn: 350093
The assertion fired (with a debug visual studio STL) because we tried to
dereference the end of a vector (although it was only to take its
address again and form an end iterator). Rewrite this logic to avoid the
questionable code.
llvm-svn: 350091
Summary:
Simplify the code by using the contains implementation in IntervalMap.
There is a slight change of behavior here: We now treat an allocation of
size 0, as if it was size 1. This guarantees that the returned addresses
will be unique, whereas previously we would allow the allocation
function to return the same zero-sized region multiple times, as long as
it is not null, and not in the middle of an existing interval (but the
situation when we were placing an larger interval over a zero-sized one
was not detected).
I think this behavior makes more sense, as that is pretty much the same
guarantee as offered by malloc (except that is permitted to also return
nullptr).
Reviewers: vsk
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55761
llvm-svn: 350087
Summary:
r346165 introduced a bug, where we would fail to parse the size of an
array if that size happened to match an existing die offset.
The logic was:
if (DWARFDIE count = die.GetReferencedDie(DW_AT_count))
num_elements = compute_vla_size(count);
else
num_elements = die.GetUsigned(DW_AT_count); // a fixed-size array
The problem with this logic was that GetReferencedDie did not take the
form class of the attribute into account, and would happily return a die
reference for any form, if its value happened to match some die.
As this behavior is inconsistent with how llvm's DWARFFormValue class
operates, I chose to fix the problem by making our version of this class
match the llvm behavior. For this to work, I had to add an explicit form
class check to the .apple_XXX tables parsing code, because they do
(incorrectly?) use data forms as die references.
Reviewers: aprantl, clayborg
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D55991
llvm-svn: 350086
Using compare is verbose, bug prone and potentially inefficient (because
of early termination). Replace relevant call sites with the (in)equality
operator.
llvm-svn: 349972
Prior to this there were 3 places that were duplicating the logic to detect if a section can/should be loaded and some were doing things a bit differently. Now it is all centralized in one place and it is done correctly.
llvm-svn: 349926
They both run the same command, and people get used to typing the shortest
string they can, so we should support alias info on shortened strings as well.
<rdar://problem/46859207>
llvm-svn: 349874
Previously we would create these for local variables but not for
global variables.
Also updated existing tests which created global variables to check
for them in the resulting AST.
llvm-svn: 349854
These are tests that found actual, but hard to fix, bugs that are
tracked elsewhere. Leaving them red only distracts from new failures
this bot finds.
llvm-svn: 349851
Unexpected successes should be considered failures because they can hide
regressions when not addressed. When a test is fixed and not re-enabled,
it can easily regress without us noticing.
I couldn't find a good way to make this change other than changing it in
the unittest2 framework. I know this is less than optimal but since we
have the dependency checked in and the change is pretty fundamental to
the framework I think it's not unreasonable.
Differential revision: https://reviews.llvm.org/D55835
llvm-svn: 349818
This test is now marked as unsupported on Windows - it is not technically "unsupported" on Windows, but it fails because "expr ptr" does not evaluate correctly. However, the error message contains the expected string, so the test "passes" despite the fact that the commands failed
The following bug has been opened for it: llvm.org/pr40119
llvm-svn: 349784
This is a set of tests that were all marked as failing becuse of pr24764. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349719
This builds on https://reviews.llvm.org/D43884 and https://reviews.llvm.org/D43886 and extends LLDB support of Obj-C exceptions to also look for a "current exception" for a thread in the C++ exception handling runtime metadata (via call to __cxa_current_exception_type). We also construct an actual historical SBThread/ThreadSP that contains frames from the backtrace in the Obj-C exception object.
The high level goal this achieves is that when we're already crashed (because an unhandled exception occurred), we can still access the exception object and retrieve the backtrace from the throw point. In Obj-C, this is particularly useful because a catch+rethrow is very common and in those cases you currently don't have any access to the throw point backtrace.
Differential Revision: https://reviews.llvm.org/D44072
llvm-svn: 349718
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349713
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349711
We had a use after free where we were assigning the result of a function
that returned a string to a StringRef. After fixing this use after
free, one of the DIA PDB tests now passes with the native PDB reader,
so we enable the test under native mode as well. The goal is to
eventually make all the tests pass under both, at which point we can
disable them all under DIA mode.
llvm-svn: 349673
This is a set of tests that were all marked as failing becuse of pr21765. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349668
This is a set of tests that were all marked as failing becuse of pr24489. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349665
Prior to this change we would show the name of the section that a memory region belonged to but not its actual region name. Now we show this,. Added a test that reuses the regions-linux-map.dmp minidump file to test this and verify the correct region names for various memory regions.
Differential Revision: https://reviews.llvm.org/D55854
llvm-svn: 349658
The build.py script always runs the compiler in C++ mode, regardless of
the file extension. This results in mangled names presented to the
linker which in turn cannot find the printf symbol.
While we figure out how to solve this issue I've turned the source file
into a cpp file and added extern c. This should unbreak the bots.
llvm-svn: 349642
Currently spawnLldbMi accepts both lldb-mi options and executable to debug as
a single parameter. Split them.
As in D55859 we will need to execute one lldb-mi command before loading the
exe. Therefore we can no longer use the exe as lldb-mi command-line parameter
as then there is no way to execute a command before loading exe specified as
lldb-mi command-line parameter.
LocateExecutableSymbolFileDsym should be static, that is also a little
refactorization.
Differential Revision: https://reviews.llvm.org/D55858
llvm-svn: 349607
We're linking against libcompression all the time now, we don't need to
fall back to zlib. zlib support will still be used when lldb is built on
linux et al systems, so I'm not removing any of the source support, but
when built on darwin with xcode, we'll be using libcompression.
llvm-svn: 349572
We reconstruct the AST hierarchy by trying to hack up a mangled
name for the parent type using the child type's mangled name.
This was failing for enums because their tag type is represented
with two letters ("W4") instead of one letter ("T", "U", etc) as
it is with classes, structs, and unions. After accounting for
this we can now correctly determine when an enum is nested
inside of a namespace or a class.
llvm-svn: 349565
systems. It has been available in the OS over over three years
now. If lldb doesn't link against -lcompression, it should be an
error.
Allocate a scratch buffer for libcompression to use when decoding
packets, instead of it having to allocate & free one on every call.
Fix a typeo with the size of the buffer that compression_decode_buffer()
is expanding into.
<rdar://problem/41601084>
llvm-svn: 349563
on Darwin systems and libcompression has been in the OS for over
three years.
Remove use of / linking to zlib. We'll always have libcompression
available now.
Create a scratch buffer via compression_encode_scratch_buffer_size()
and use it in calls to compression_encode_buffer() to avoid
compression_encode_buffer having to malloc & free a scratch buffer
on each call.
Tested by forcing compression to be enabled on macos native (normally
only enabled on iOS et al devices), running the testsuite.
<rdar://problem/41601084>
llvm-svn: 349553
As discussed on IRC this morning, when building an in-tree clang for
testing we have to have libcxx and libcxxabi checked out. This is a
common pitfall. Not only are the resulting failures non-obvious, they
only manifest when running the test suite, *after* building lldb and
clang. By making them a hard dependency (on macOS) we fail earlier with
a more useful error message.
Differential revision: https://reviews.llvm.org/D55837
llvm-svn: 349539
Summary:
GnuWin32 installs libxml2 2.4. This isn't recent enough for lldb's
usage and thus the build fails. Searching for libxml2 was disabled
due to this build failure.
However, the gdb-remote plugin requires libxml2 to parse various
gdb-remote protocol packets. Thus check and confirm that the libxml2
version is at least 2.8 and disable it if not.
Reviewers: compnerd, zturner
Reviewed By: compnerd
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D55583
llvm-svn: 349538
Summary:
The first section header does not define a real section. Instead it is
used for various elf extensions. This patch skips creation of a section
for index 0.
This has one furtunate side-effect, in that it allows us to use the section
header index as the Section ID (where 0 is also invalid). This way, we
can get rid of a lot of spurious +1s in the ObjectFileELF code.
Reviewers: clayborg, krytarowski, joerg, espindola
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D55757
llvm-svn: 349498
the "self.assertEqual(thread.GetStopReason(), lldb.eStopReasonSignal)"
was occasionally failing because the stop reason would come out as
"trace" this happened if we issued the interrupt just as the processed
stopped due to single-stepping over the breakpoint (i.e., the it was not
necessary to send any signal).
Fix this by removing the breakpoint before resuming the process. This
ensures the process can run unobstructed.
After this, the test passed 200 consecutive runs successfully for me,
even while the system was under heavy load.
llvm-svn: 349491
This test was disabled in r326756 as a part of "upstreaming debugserver
support for AVX-512 (zmm register set)". This looks like an error
because both register set and remote stubs are different.
In any case, the test passes now.
llvm-svn: 349485
This test is passing now on linux. The same test is claimed to be flaky
on darwin, so it's possible that's true on linux too. If that's the case
we'll have to skip it here too (or fix it).
I mark the test as not-debug-info-dependent as a drive-by.
llvm-svn: 349482
These tests are now passing on linux, at least with top-of-tree clang,
clang-6 and gcc-7.3. It's possible it may still be failing with some
older compilers, but I don't have those around to test.
llvm-svn: 349478
Summary:
This should enable the compiler to find the system linker for the link
step.
Reviewers: stella.stamenova, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55736
llvm-svn: 349461
We need to ensure that Finalize gets called before we start
to destroy the old Process or the weak_ptr->shared_ptr link
from Threads to Target gets broken before the threads are
destroyed.
<rdar://problem/43586979>
Differential Revision: https://reviews.llvm.org/D55631
llvm-svn: 349435
Each process plug-in can create its own custom commands. I figured it would be nice to be able to dump things from the minidump file from the lldb command line, so I added the start of the some custom commands.
Currently you can dump:
minidump stream directory
all linux specifc streams, most of which are strings
each linux stream individually if desired, or all with --linux
The idea is we can expand the command set to dump more things, search for data in the core file, and much more. This patch gets us started.
Differential Revision: https://reviews.llvm.org/D55727
llvm-svn: 349429
present in the dSYM per-uuid plist, its precedence order with
the older DBGBuildSourcePath/DBGSourcePath, and note that
must be present and have a value of 3 or the dictionary
will be ignored.
<rdar://problem/46421686>
llvm-svn: 349409
make the executable name more unique.
This test is failing sporadically on some bots. By removing the sleep
synchronisation, I'm hoping to get it to fail more reproducibly so I
can investigate what is going on.
llvm-svn: 349397
Previously the code that parsed debug info to create lldb's Symbol
objects such as Variable, Type, Function, etc was tightly coupled
to the AST reconstruction code. This made it difficult / impossible
to implement functions such as ParseDeclsForContext() that were only
supposed to be operating on clang AST's. By splitting these apart,
the logic becomes much cleaner and we have a clear separation of
responsibilities.
llvm-svn: 349383
The --repl option was incorrectly defined as "Separate" (option and
value separated by a space). This resulted in the option not being
picked up when no value was specified.
This patch fixes the driver so that `--repl` is recognized again. I
split the option into two:
- A flag: `--repl` and `-r` which take no arguments.
- A joined option: `--repl=<flags>` and `-r=<flags>` that forward its
values to the repl.
This should match the driver's old behavior.
llvm-svn: 349371
This is a little dangerous since the crashlog files aren't 100%
unambiguous, but the risk is mitigated by using a non-greedy +?
pattern.
rdar://problem/38478511
Differential Revision: https://reviews.llvm.org/D55608
llvm-svn: 349367
Often users have a crash log an d a .dSYM bundle, but not the original
application binary. It turns out that for crash symbolication, we can
safely fall back to using the binary inside the .dSYM bundle.
Differential Revision: https://reviews.llvm.org/D55607
llvm-svn: 349366
The first one allows us to add an enumerator to an enum if we
already have an APSInt, since ultimately the implementation just
constructs one anyway. The second is just a general utility
function to covert a CompilerType to a clang::TagDecl.
llvm-svn: 349360
gdb-remote serial protocol documentation, call out the
incompatability of lldb's vFile:open: packet as it stands
today. Need to think about whether to change lldb's
enum values (breaking any existing lldb-server's out there)
or create a different packet and abandon vFile:open: at
least for a while.
llvm-svn: 349316
in the packet are lldb enum values, not the open(2) oflags --
forgot about that wrinkle. Also added a comment to File.h
noting that the existing values cannot be modified or we'll
have a compatibilty break with any alternative platform
implementations, or older versions of lldb-server.
llvm-svn: 349282
Summary:
Previously lldb-test's LinePrinter would output the indentation spaces
even on completely empty lines. This is not nice, as trailing spaces get
flagged as errors in some tools/editors, and it prevents FileCheck's
CHECK-EMPTY from working.
Equally annoying was the fact that the LinePrinter did not terminate
it's output with a newline (instead it would leave the unterminated hanging
indent from the last NewLine() command), which meant that the shell prompt
following the lldb-test command came out wrong.
This fixes both issues by changing how newlines are handled. NewLine(),
which was ending the previous line ('\n') *and* begging the next line by
printing the indent, is now "demoted" to just printing literal "\n".
Instead, lines are now delimited via a helper Line object, which makes
sure the line is indented and terminated in an RAII fashion. The typical
usage would be:
Printer.line() << "This text will be indented and terminated";
If one needs to do more work than it will fit into a single statement,
one can also assign the result of the line() function to a local
variable. The line will then be terminated when that object goes out of
scope.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55597
llvm-svn: 349269
Summary:
This patch attempts to move as much code as possible out of the
CreateSections function to make room for future improvements there. Some
of this may be slightly over-engineered (VMAddressProvider), but I
wanted to keep the logic of this function very simple, because once I
start taking segment headers into acount (as discussed in D55356), the
function is going to grow significantly.
While in there, I also added tests for various bits of functionality.
This should be NFC, except that I changed the order of hac^H^Heuristicks
for determining section type slightly. Previously, name-based deduction
(.symtab -> symtab) would take precedence over type-based (SHT_SYMTAB ->
symtab) one. In fact we would assert if we ran into a .text section with
type SHT_SYMTAB. Though unlikely to matter in practice, this order
seemed wrong to me, so I have inverted it.
Reviewers: clayborg, krytarowski, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D55706
llvm-svn: 349268
to write an lldb platform server that doesn't link against
LLDB.framework to be able to fully run the lldb testsuite
on a remote system. The platform packets weren't covered
in the existing lldb-gdb-remote.txt doc, so I wanted to
jot them down in one place.
llvm-svn: 349231
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
While I was out hunting for remaining pexpect-based tests, I came
across these tests that can't possibly work an any modern system, as
they rely on having gdb available in /Developer.
This patch simply removes the test without replacement.
Differential Revision: https://reviews.llvm.org/D55559
llvm-svn: 349194
Breakpad creates minidump files that sometimes have:
- linux maps textual content
- no MemoryInfoList
Right now unless the file has a MemoryInfoList we get no region information.
This patch:
- reads and caches the memory region info one time and sorts it for easy subsequent access
- get the region info from the best source in this order:
- linux maps info (if available)
- MemoryInfoList (if available)
- MemoryList or Memory64List
- returns memory region info for the gaps between regions (before the first and after the last)
Differential Revision: https://reviews.llvm.org/D55522
llvm-svn: 349182
Since we're actually running an executable on the host now, different
versions of Windows could load different system libraries, so we need
to regex out the number of loaded modules.
llvm-svn: 349175
Summary:
These are general purpose "utility" classes, whose functionality is not
debugger-specific in any way. As such, I believe they belong in the
Utility module.
This doesn't break any particular dependency (yet), but it reduces the
number of Core dependencies across the board.
Reviewers: zturner, jingham, teemperor, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D55361
llvm-svn: 349157
This commit added new test inputs, but it did not add them to the cmake
files. This caused the test to fail at runtime.
While in there, I also sorted the list of minidump test inputs.
llvm-svn: 349154
It turns out it wasn't the compilers, but swig who had issues with my
previous patch -- older versions do not recognise the "constexpr"
keyword.
Fortunately, that can be fixed the same way we fix all other swig
incompatibilities: #ifndef SWIG.
llvm-svn: 349153
this allows one to use bitwise operators on the variables of this type
without complicated casting.
The gotcha here is that the combinations of these enums were being used
in some constexpr contexts such as case labels (case
ePermissionsWritable | ePermissionsExecutable:), which is not possible
if the user-defined operator| is not constexpr.
So, this commit also marks these operators as constexpr. I am committing
this as a small standalone patch so it can be easily reverted if some
compiler has an issue with this.
llvm-svn: 349149
This patch adds support for parsing and evaluating local variables.
using the native pdb plugin.
Differential Revision: https://reviews.llvm.org/D55575
llvm-svn: 349067
The MinidumpParser::GetFilteredModuleList() code was attempting to iterate through the entire module list and if it found more than one entry for a given module name, it wanted to pick the MinidumpModule with the lowest address. A bug existed where it wasn't doing that due to "exists" variable being inverted. "exists" was set to true if it was inserted, not if it existed. Furthermore, the order of the modules would be modified by sorting all modules from low address to high address (using MinidumpModule::base_of_image). This fix also maintains the original order which means your executable is at index 0 as intended instead of some random shared library.
Tests were added to ensure this functionality doesn't regress.
Differential Revision: https://reviews.llvm.org/D55614
llvm-svn: 349062
We've recently developed a convention where the tests are placed into
subfolders according to the object file type. This applies that
convention to existing tests too.
llvm-svn: 349027
Previously CreateParameterDeclaration was always using the translation
unit DeclContext. We would later go and add parameters to the
FunctionDecl, but internally clang makes a copy when you do this, and
we'd end up with ParmVarDecl's at the global scope as well as in the
function scope.
This fixes the issue. It's hard to say whether this will introduce
a behavioral change in name lookup, but I know there have been several
hacks introduced in previous years to deal with collisions between
various types of variables, so there's a chance that this patch could
obviate one of those hacks.
Differential Revision: https://reviews.llvm.org/D55571
llvm-svn: 348941
Move code into a separate function, and replace the if-else chain with
llvm::StringSwitch.
A slight behavioral change is that now I use the section flags
(SHF_TLS) instead of the section name to set the thread-specific
property. There is no explanation in the original commit introducing
this (r153537) as to why that was done this way, but the new behavior
should be more correct.
llvm-svn: 348936
Instead of GetProgramHeaderCount+GetProgramHeaderByIndex, expose an
ArrayRef of all program headers, to enable range-based iteration.
Instead of GetSegmentDataByIndex, expose GetSegmentData, taking a
program header (reference).
This makes the code simpler by enabling range-based loops and also
allowed to remove some null checks, as it became locally obvious that
some pointers can never be null.
llvm-svn: 348928
Previously, lldb-test would only print top-level sections. However, in
lldb, sections can contain other sections. This teaches lldb-test to
print nested sections too.
llvm-svn: 348924
Summary:
This implements the gcc builder in build.py script to allow it to
compile host executables when running on a non-windows host. Where it
made sense, I tried to share code with the msvc builder by moving stuff
to the base class.
Reviewers: zturner
Subscribers: mehdi_amini, dexonsmith, lldb-commits
Differential Revision: https://reviews.llvm.org/D55430
llvm-svn: 348918
Hopefully this makes the option data easier to understand and maintain.
- Group the member variables.
- Do the initialization in the header as it's less error prone.
- Rename the Clean method. It was called only once and was
re-initializing some but not all (?) members. The only useful thing it
does is dealing with the local lldbinit file so keep that and make the
name reflect that.
llvm-svn: 348894
Summary:
This function was named such because in the case of MachO files, the
mach header is located at this address. However all (most?) usages of
this function were not interested in that fact, but the fact that this
address is used as the base address for expressing various relative
addresses in the object file.
For other object file formats, this name is not appropriate (and it's
probably the reason why this function was not implemented in these
classes). In the ELF case the ELF header will usually end up at this
address, but this is a result of the linker optimizing the file layout
and not a requirement of the spec. For COFF files, I believe the is no
header located at this address either.
Reviewers: clayborg, jasonmolenda, amccarth, lemo, stella.stamenova
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55422
llvm-svn: 348849
m_loc_is_constant_data was uninitialized, so unless someone
explicitly called SetLocIsConstantData(), this would be UB.
I think every existing call-site would always call the proper
function to initialize the value, so there were no existing
bugs, but I encountered this when I tried to use it without
calling this function and encountered this.
llvm-svn: 348813
Summary: Instead use a more reasonable value to start and rely on the fact that SmallString will resize if necessary.
Reviewers: labath, asmith
Reviewed By: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55457
llvm-svn: 348775
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
The test still only passes when not run from VS because the previous patch did not remove the original build commands.... This also simplifies the build command by removing some defaults
llvm-svn: 348664
Previously we would create an lldb::Function object for each function
parsed, but we would not add these to the clang AST. This is a first
step towards getting local variable support working, as we first need an
AST decl so that when we create local variable entries, they have the
proper DeclContext.
Differential Revision: https://reviews.llvm.org/D55384
llvm-svn: 348631
Summary:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348592
And mark it as a public header so it will get copied
into the LLDB.framework. A handful of "api" tests were
failing because they couldn't find this file.
llvm-svn: 348561
in one packet from 1k bytes to 16k bytes. Sending a large file to an
iOS device directly connected by USB cable, to lldb-server running in
platform mode, this speeds up the file xfer by 77%. Sending the file
in 32k blocks speeds up the file xfer by 80% versus 1k blocks, starting
with 16k to make sure we don't have any problems with android testing.
We may not have the same perf characteristics over ethernet, but with
USB it's faster to send fewer larger packets than many small packets.
llvm-svn: 348557
Windows provides a Yield function-like macro that allows a thread to
yield the CPU. However, this conflicts with `Yield` in swift. Undefine
`Yield` to allow building lldb with swift support.
llvm-svn: 348556
Summary:
This parses entries in pecoff import tables for imported DLLs and
is intended as the first step to allow LLDB to load a PE's shared
modules when creating a target on the LLDB console.
Reviewers: rnk, zturner, aleksandr.urakov, lldb-commits, labath, asmith
Reviewed By: labath, asmith
Subscribers: labath, lemo, clayborg, Hui, mgorny, mgrang, teemperor
Differential Revision: https://reviews.llvm.org/D53094
llvm-svn: 348527
Summary:
Windows lldb debugging currently uses a process plugin to handle
launching and attaching to a process. Launching a process via a debug
server (e.g. ds2) and attaching to it with `gdb-remote port` currently
doesn't communicate address information of the executable properly.
Implement DynamicLoaderWindowsDYLD::DidAttach which allow us to
obtain the proper executable load address.
Differential Revision: https://reviews.llvm.org/D55383
llvm-svn: 348526
In compile-and-link mode, the user doesn't specify the name of the
object files to generate, because there could be multiple inputs
on a single command line and this would be hard to specify. So the
script just tries to be smart and figure out the best object file
names. However, if two build scripts are running in parallel and
using the same source files as input, they would previously race
to write the same object files, since the computed name only considered
the source file names when computing the object file names.
With this patch, we also consider the final executable name. In a
way, this "namespaces" the generated object files so that as long
as the final executable file names don't clash, the intermediate
object file names won't clash either.
llvm-svn: 348511
VarStreamArray was built on the assumption that it is backed by a
StreamRef, and offset 0 of that StreamRef is the first byte of the first
record in the array.
This is a logical and intuitive assumption, but unfortunately we have
use cases where it doesn't hold. Specifically, a PDB module's symbol
stream is prefixed by 4 bytes containing a magic value, and the first
byte of record data in the array is actually at offset 4 of this byte
sequence.
Previously, we would just truncate the first 4 bytes and then construct
the VarStreamArray with the resulting StreamRef, so that offset 0 of the
underlying stream did correspond to the first byte of the first record,
but this is problematic, because symbol records reference other symbol
records by the absolute offset including that initial magic 4 bytes. So
if another record wants to refer to the first record in the array, it
would say "the record at offset 4".
This led to extremely confusing hacks and semantics in loading code, and
after spending 30 minutes trying to get some math right and failing, I
decided to fix this in the underlying implementation of VarStreamArray.
Now, we can say that a stream is skewed by a particular amount. This
way, when we access a record by absolute offset, we can use the same
values that the records themselves contain, instead of having to do
fixups.
Differential Revision: https://reviews.llvm.org/D55344
llvm-svn: 348499
When building with MSVC, the type `Module` is ambiguous due to both the
lldb_private and llvm namespaces being used. Use the elaborated type
instead to resolve the ambiguity.
llvm-svn: 348332
This makes -mode=compile support multiple inputs (and hence
multiple outputs).
It also makes the value of -arch for compiling inferiors default
to the architecture that LLDB is built in. This can still be
overridden however.
Differential Revision: https://reviews.llvm.org/D55230
llvm-svn: 348305
As Pavel noted on the mailing list we should only create the bottom-most
directory if it doesn't exist. This should also fix the test case on
Windows as we can use lit's temp directory.
llvm-svn: 348289
Summary:
r348240 assumes that an expression contains the Objective C option if
Objective C Runtime is found. But on MacOS X it seems that the test application
process always contains Objective C Runtime, so the test fails when it assumes
that the language is C++ only. Skip this part on Darwin.
llvm-svn: 348250
Summary:
This patch adds the check of the language before ignoring names like `id` or
`Class`, which are reserved in Objective C, but are allowed in C++. It is needed
to make it possible to evaluate expressions in a C++ program containing names
like `id` or `Class`.
Reviewers: jingham, zturner, labath, clayborg
Reviewed By: jingham, clayborg
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D54843
llvm-svn: 348240
This patch changes the way the reproducer is initialized. Rather than
making changes at run time we now do everything at initialization time.
To make this happen we had to introduce initializer options and their SB
variant. This allows us to tell the initializer that we're running in
reproducer capture/replay mode.
Because of this change we also had to alter our testing strategy. We
cannot reinitialize LLDB when using the dotest infrastructure. Instead
we use lit and invoke two instances of the driver.
Another consequence is that we can no longer enable capture or replay
through commands. This was bound to go away form the beginning, but I
had something in mind where you could enable/disable specific providers.
However this seems like it adds very little value right now so the
corresponding commands were removed.
Finally this change also means you now have to control this through the
driver, for which I replaced --reproducer with --capture and --replay to
differentiate between the two modes.
Differential revision: https://reviews.llvm.org/D55038
llvm-svn: 348152
Summary:
This patch contains several small fixes, which makes it possible to evaluate
expressions on Windows using information from PDB. The changes are:
- several sanitize checks;
- make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic
value on a failure, because callers wait 0 in this case;
- entry point required to be a file address, not RVA, in the ObjectFilePECOFF;
- do not crash on a debuggee second chance exception - it may be an expression
evaluation crash. Also fix detection of "crushed" threads in tests;
- create parameter declarations for functions in AST to make it possible to call
debugee functions from expressions;
- relax name searching rules for variables, functions, namespaces and types. Now
it works just like in the DWARF plugin;
- fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc.
Reviewers: zturner, asmith, stella.stamenova
Reviewed By: stella.stamenova, asmith
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53759
llvm-svn: 348136
This adds a script called build.py as well as a lit substitution
called %build that we can use to invoke it. The idea is that
this allows a lit test to build test inferiors without having
to worry about architecture / platform specific differences,
command line syntax, finding / configurationg a proper toolchain,
and other issues. They can simply write something like:
%build --arch=32 -o %t.exe %p/Inputs/foo.cpp
and it will just work. This paves the way for being able to
run lit tests with multiple configurations, platforms, and
compilers with a single test.
Differential Revision: https://reviews.llvm.org/D54914
llvm-svn: 348058
1. In ProcessWindows if we fail to allocate memory, we need to return LLDB_INVALID_ADDRESS rather than 0 or nullptr as that is the invalid address that LLDB looks for
2. In RegisterContextWindows in ReadAllRegisterValues, always create a new buffer. This is what the other platforms do and data_sp is always null in all tested scenarios on Windows as well
llvm-svn: 348055
The test assumes that HW breakpoints are not implemented by the debug
server. Windows doesn't use these and might actually support HW
breakpoints so these tests are expected fail because they don't raise
the expected error.
llvm-svn: 348010
This reverts commit dec87759523b2f22fcff3325bc2cd543e4cda0e7.
This commit caused the tests on Windows to run forever rather than complete.
Reverting until the commit can be fixed to not stall.
llvm-svn: 348009
Summary:
This patch fixes the next situation. On Windows clang-cl makes no stub before
the main function, so the main function is located exactly on module entry
point. May be it is the same on other platforms. So consider the following
sequence:
- set a breakpoint on main and stop there;
- try to evaluate expression, which requires a code execution on the debuggee
side. Such an execution always returns to the module entry, and the plan waits
for it there;
- the plan understands that it is complete now and removes its breakpoint. But
the breakpoint site is still there, because we also have a breakpoint on
entry;
- StopInfo analyzes a situation. It sees that we have stopped on the breakpoint
site, and it sees that the breakpoint site has owners, and no one logical
breakpoint is internal (because the plan is already completed and it have
removed its breakpoint);
- StopInfo thinks that it's a user breakpoint and skips it to avoid recursive
computations;
- the program continues.
So in this situation the program continues without a stop right after
the expression evaluation. To avoid this an additional check that
the plan was completed was added.
Reviewers: jingham, zturner, boris.ulasevich
Reviewed by: jingham
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53761
llvm-svn: 347974
Summary:
This patch contains several small fixes, which makes it possible to evaluate
expressions on Windows using information from PDB. The changes are:
- several sanitize checks;
- make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic
value on a failure, because callers wait 0 in this case;
- entry point required to be a file address, not RVA, in the ObjectFilePECOFF;
- do not crash on a debuggee second chance exception - it may be an expression
evaluation crash;
- create parameter declarations for functions in AST to make it possible to call
debugee functions from expressions;
- relax name searching rules for variables, functions, namespaces and types. Now
it works just like in the DWARF plugin;
- fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc.
Reviewers: zturner, asmith, stella.stamenova
Reviewed By: stella.stamenova, asmith
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53759
llvm-svn: 347962
Summary:
This patch adds possibility of searching a public symbol with name and type in
a symbol file, not only in a symtab. It is helpful when working with PE, because
PE's symtabs contain only imported / exported symbols only. Such a search is
required for e.g. evaluation of an expression that calls some function of
the debuggee.
Reviewers: zturner, asmith, labath, clayborg, espindola
Reviewed By: clayborg
Subscribers: davide, emaste, arichardson, aleksandr.urakov, jingham,
lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53368
llvm-svn: 347960
Apparently LLVM's libSupport depends on libDemangle to print the stack
trace. I'm not sure if this is desired but for now we don't have much
choice if we want to turn to bot green again.
llvm-svn: 347952
This fixes the driver with the Xcode project. We need to link the driver
against the correct LLVM libraries and make sure we're disabling
exceptions/rtti.
Thanks to Jim for helping me figure this out.
llvm-svn: 347936
Earlier this month there was a change in clang that defaulted to using codeview rather than dwarf on Windows. Since all the tests rely on dwarf, we need to explicitly request dwarf when building on Windows.
llvm-svn: 347924
A skeleton compilation unit may contain the DW_AT_str_offsets_base attribute
that points to the first string offset of the CU contribution to the
.debug_str_offsets. At the same time, when we use split dwarf,
the corresponding split debug unit also
may use DW_FORM_strx* forms pointing to its own .debug_str_offsets.dwo.
In that case, DWO does not contain DW_AT_str_offsets_base, but LLDB
still need to know and skip the .debug_str_offsets.dwo section header to
access the offsets.
The patch implements the support of DW_AT_str_offsets_base.
Differential revision: https://reviews.llvm.org/D54844
llvm-svn: 347859
The changed order of includes caused compile errors on MSVC due to
snprintf macro definition. snprintf should available since VS2015, and
the rest of the code seems to be able to use snprintf just fine without
this macro, so this removes it from the lldb driver as well.
llvm-svn: 347855
They are not needed now that we use LLVMOption for command-line parsing
thank you, Jonas). This also allows us to avoid linking of lldbHost
into the driver which was breaking liblldb encapsulation.
(Technically, there is still a lldb/Host/windows/windows.h include which
is needed on windows, but this is a header-only wrapper for <windows.h>,
so it is not necessary to link lldbHost for that. But ideally, that
should go away too.)
llvm-svn: 347846
The issue happens because starting from DWARF v5
DW_AT_addr_base attribute should be used
instead of DW_AT_GNU_addr_base. LLDB does not do that and
we end up reading the .debug_addr header as section content
(as addresses) instead of skipping it and reading the real addresses.
Then LLDB is unable to match 2 similar locations and
thinks they are different.
Differential revision: https://reviews.llvm.org/D54751
llvm-svn: 347842
Because the optarg variable was shadowed we didn't notice we weren't
extracting the value from the option. This patch fixes that and renames
the variable to prevent this from happening in the future.
I also added two tests to check the error output for --core and --file
when the given value doesn't exist.
llvm-svn: 347821
This adds new APIs and a command to deal with exceptions (mostly Obj-C exceptions): SBThread and Thread get GetCurrentException API, which returns an SBValue/ValueObjectSP with the current exception for a thread. "Current" means an exception that is currently being thrown, caught or otherwise processed. In this patch, we only know about the exception when in objc_exception_throw, but subsequent patches will expand this (and add GetCurrentExceptionBacktrace, which will return an SBThread/ThreadSP containing a historical thread backtrace retrieved from the exception object. Currently unimplemented, subsequent patches will implement this).
Extracting the exception from objc_exception_throw is implemented by adding a frame recognizer.
This also add a new sub-command "thread exception", which prints the current exception.
Differential Revision: https://reviews.llvm.org/D43886
llvm-svn: 347813
Two of the file system tests are failing on Windows - this updates them to expect the correct values after the refactor of the file system code.
llvm-svn: 347796
A couple of new tests have been added that use existing class names. This causes failures on Windows if the tests run at the same time and on any platform it results in the logs being overwritten.
llvm-svn: 347717
When I landed the initial reproducer framework I knew there were some
things that needed improvement. Rather than bundling it with a patch
that adds more functionality I split it off into this patch. I also
think the API is stable enough to add unit testing, which is included in
this patch as well.
Other improvements include:
- Refactor how we initialize the loader and generator.
- Improve naming consistency: capture and replay seems the least ambiguous.
- Index providers by name and make sure there's only one of each.
- Add convenience methods for creating and accessing providers.
Differential revision: https://reviews.llvm.org/D54616
llvm-svn: 347716
On Windows, when using the VFS without going through FileSpec, the
absolute path to `/foo` is `\\foo`. This updates the unittest to expect
that.
llvm-svn: 347712
This patch modifies the lldb driver to use libOption for option parsing.
It allows us to decouple option parsing from option processing which is
important when arguments affect initialization. This was previously not
possible because the debugger need to be initialized as some option
interpretation (like the scripting language etc) was handled by the
debugger, rather than in the driver.
Differential revision: https://reviews.llvm.org/D54692
llvm-svn: 347709
When trying to fix the bots we expected that the cast would be needed in
different places. Ultimately it turned out only the
SymbolFileDWARFDebugMap was affected so, as Pavel correctly notes, it
makes more sense to do the cast just there instead of in teh FS.
llvm-svn: 347660
Summary:
This change adds eLanguageTypeDylan to the set of languages supported
by ClangASTContext. Debug info generated by the Open Dylan compiler's
LLVM back-end was designed to be compatible with C debug info.
Patch by Peter Housel.
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: brucem, lldb-commits, aprantl
Differential Revision: https://reviews.llvm.org/D54886
llvm-svn: 347637
After a recent change in LLVM the TimePoint encoding become more
precise, exceeding the precision of the TimePoint obtained from the
DebugMap. This patch adds a flag to the GetModificationTime helper in
the FileSystem to return the modification time with less precision.
Thanks to Davide for bisecting this failure on the LLDB bots.
llvm-svn: 347615
Summary: SetMustBuildLookupTable() must always be called on a primary context.
Reviewers: labath, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411
Differential Revision: https://reviews.llvm.org/D54863
llvm-svn: 347575
Summary: Right now only some platforms add pthread to the compilation, however, at least one of the tests requires the pthread library on Linux as well. Since the library is available, this change adds it by default on Linux.
Reviewers: labath, zturner, asmith
Subscribers: stella.stamenova, jfb, lldb-commits
Differential Revision: https://reviews.llvm.org/D54808
llvm-svn: 347412
If we just invoke clang-cl without specifying the linker, the tests fail on Windows because they cannot find the correct linker to use, so it needs to be specified explicitly
llvm-svn: 347323
Summary:
Use llvm_codesign to sign debugserver with entitlements.
Set global LLVM_CODESIGNING_IDENTITY from LLDB_CODESIGN_IDENTITY (if given).
Pass through ENTITLEMENTS from add_lldb_executable to add_llvm_executable.
Handle reconfigurations correctly.
We have a lot of cases, make them explicit:
(1) build and sign debugserver, if all conditions apply:
* LLDB_NO_DEBUGSERVER=OFF (default)
* On Darwin: LLDB_USE_SYSTEM_DEBUGSERVER=OFF (default)
* On Darwin: LLVM_CODESIGNING_IDENTITY == lldb_codesign
(2) use system debugserver, if on Darwin and any of:
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and found on system (explicit case)
* LLVM_CODESIGNING_IDENTITY != lldb_codesign and found on system (fallback case)
(3) debugserver will not be available, in case of:
* LLDB_NO_DEBUGSERVER=ON
* On Darwin: LLVM_CODESIGNING_IDENTITY != lldb_codesign and not found on system
(4) error state, in case of:
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and not found on system
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and LLDB_NO_DEBUGSERVER=ON
Reviewers: xiaobai, beanz, vsk, JDevlieghere
Subscribers: mgorny, lldb-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D54476
llvm-svn: 347305
Otherwise, the clang analyzer tests fail on Windows when attempting to
unpickle AnalyzerTest objects in the worker processes. The pattern of,
add to path, import, remove from path, serialize, deserialize, doesn't
work. Once something gets added to the path, if we want to move it
across the wire for multiprocessing, we need to keep the module on
sys.path.
llvm-svn: 347254
Summary: In order to invoke sed on Windows, we need to quote the command correctly. Since we already have commands which do that, move the definitions at the beginning of the file and then re-use them for each command.
Reviewers: aprantl, zturner
Subscribers: teemperor, lldb-commits
Differential Revision: https://reviews.llvm.org/D54709
llvm-svn: 347243
Recently I tried to port LLDB's lit configuration files over to use a
on the surface, but broke some cases that weren't broken before and also
exposed some additional problems with the old approach that we were just
getting lucky with.
When we set up a lit environment, the goal is to make it as hermetic as
possible. We should not be relying on PATH and enabling the use of
arbitrary shell commands. Instead, only whitelisted commands should be
allowed. These are, generally speaking, the lit builtins such as echo,
cd, etc, as well as anything for which substitutions have been
explicitly set up for. These substitutions should map to the build
output directory, but in some cases it's useful to be able to override
this (for example to point to an installed tools directory).
This is, of course, how it's supposed to work. What was actually
happening is that we were bringing in PATH and LD_LIBRARY_PATH and then
just running the given run line as a shell command. This led to problems
such as finding the wrong version of clang-cl on PATH since it wasn't
even a substitution, and flakiness / non-determinism since the
environment the tests were running in would change per-machine. On the
other hand, it also made other things possible. For example, we had some
tests that were explicitly running cl.exe and link.exe instead of
clang-cl and lld-link and the only reason it worked at all is because it
was finding them on PATH. Unfortunately we can't entirely get rid of
these tests, because they support a few things in debug info that
clang-cl and lld-link don't (notably, the LF_UDT_MOD_SRC_LINE record
which makes some of the tests fail.
The high level changes introduced in this patch are:
1. Removal of functionality - The lit test suite no longer respects
LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. This means there is no
more support for gcc, but nobody was using this anyway (note: The
functionality is still there for the dotest suite, just not the lit test
suite). There is no longer a single substitution %cxx and %cc which maps
to <arbitrary-compiler>, you now explicitly specify the compiler with a
substitution like %clang or %clangxx or %clang_cl. We can revisit this
in the future when someone needs gcc.
2. Introduction of the LLDB_LIT_TOOLS_DIR directory. This does in spirit
what LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER used to do, but now
more friendly. If this is not specified, all tools are expected to be
the just-built tools. If it is specified, the tools which are not
themselves being tested but are being used to construct and run checks
(e.g. clang, FileCheck, llvm-mc, etc) will be searched for in this
directory first, then the build output directory.
3. Changes to core llvm lit files. The use_lld() and use_clang()
functions were introduced long ago in anticipation of using them in
lldb, but since they were never actually used anywhere but their
respective problems, there were some issues to be resolved regarding
generality and ability to use them outside their project.
4. Changes to .test files - These are all just replacing things like
clang-cl with %clang_cl and %cxx with %clangxx, etc.
5. Changes to lit.cfg.py - Previously we would load up some system
environment variables and then add some new things to them. Then do a
bunch of work building out our own substitutions. First, we delete the
system environment variable code, making the environment hermetic. Then,
we refactor the substitution logic into two separate helper functions,
one which sets up substitutions for the tools we want to test (which
must come from the build output directory), and another which sets up
substitutions for support tools (like compilers, etc).
6. New substitutions for MSVC -- Previously we relied on location of
MSVC by bringing in the entire parent's PATH and letting
subprocess.Popen just run the command line. Now we set up real
substitutions that should have the same effect. We use PATH to find
them, and then look for INCLUDE and LIB to construct a substitution
command line with appropriate /I and /LIBPATH: arguments. The nice thing
about this is that it opens the door to having separate %msvc-cl32 and
%msvc-cl64 substitutions, rather than only requiring the user to run
vcvars first. Because we can deduce the path to 32-bit libraries from
64-bit library directories, and vice versa. Without these substitutions
this would have been impossible.
Differential Revision: https://reviews.llvm.org/D54567
llvm-svn: 347216
Because of different shell quoting rules, and the fact that LLDB
commands often contain spaces, -O is not portable for writing command
lines. Instead, we should use explicit lldbinit files.
Differential Revision: https://reviews.llvm.org/D54680
llvm-svn: 347213
Those tests were using pexpect and being flaky on some of ours bots.
This patch reimplmeents the tests usinf FileCheck, and it also
extends the test coverage to a few more stop-hook options.
llvm-svn: 347109
This saves about 3 redundant gigabytes from the Objective-C test build
directories. Tests that must do unsavory things with the LLDB clang
module cache, already specify a per-test module cache in their .py
test instructions.
<rdar://problem/36002081>
Differential Revision: https://reviews.llvm.org/D54602
llvm-svn: 347057
Just to be safe, up until now each test used its own Clang module
cache directory. Since the compiler within one testsuite doesn't
change it is just as safe to share a clang module directory inside the
LLDB test build directory. This saves us from compiling tens of
gigabytes of redundant Darwin and Foundation .pcm files and also
speeds up running the test suite quite significantly.
rdar://problem/36002081
Differential Revision: https://reviews.llvm.org/D54601
llvm-svn: 347056
Originally we created our 64-bit UID scheme by using the first byte as
sort of a "tag" to represent what kind of symbol this was, and we
re-used the PDB_SymType enumeration for this. For native pdb support,
this is not really the right abstraction layer, because what we really
want is something that tells us *how* to find the symbol. This means,
specifically, is in the globals stream / public stream / module stream /
TPI stream / etc, and for whichever one it is in, where is it within
that stream?
A good example of why the old namespacing scheme was insufficient is
that it is more or less impossible to create a uid for a field list
member of a class/struction/union/enum that tells you how to locate
the original record.
With this new scheme, the first byte is no longer a PDB_SymType enum
but a new enum created specifically to identify where in the PDB
this record lives. This gives us much better flexibility in
what kinds of symbols the uids can identify.
llvm-svn: 347018
Summary:
This commit implements basic DidAttach and DidLaunch for the windows
DynamicLoader plugin which allow us to load shared libraries from the
inferior.
Reviewers: sas, zturner
Reviewed By: zturner
Differential Revision: https://reviews.llvm.org/D54544
llvm-svn: 346994
Summary:
Windows make will search for other shells and choose those over cmd
if available (e.g. C:\cygdrive\bin\sh.exe). This shell has numerous
issues with path handling (/ vs \\ vs \ and C:). So default to using
cmd.exe which is known to work.
Reviewers: zturner, sas, xiaobai
Reviewed By: zturner
Differential Revision: https://reviews.llvm.org/D54510
llvm-svn: 346993
Summary:
Highlighing junk data on VSCode can send a query for evaluate which
fails. In particular cases on Windows, this the error message can end
up as a c-string of [-35,-35,-35,-35,...]. Attempting to emplace this
as the error message causes an assert failure.
Prior to emplacing the error message, confirm that it is valid UTF8 to
eliminate errors such as mentione above.
Reviewers: xiaobai, clayborg
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D53008
llvm-svn: 346988
Xcode 10 doesn't ship with an i386 SDK any more. This patch ports the
testcase from an i386/x86_64 -> x86_64/x86_64h universal binary.
rdar://problem/46099343
llvm-svn: 346981
This was introduced in r346775. Previously the ABI shared_ptr
was declared as a function local static meaning it would live
forever. After the change, someone has to create a strong
reference to it or it will go away. In this code, we were
calling ABI::FindPlugin(...).get(), so it was being immediately
destroyed and we were holding onto a dangling pointer.
llvm-svn: 346932
When debugging read-only memory we cannot use software breakpoint. We
already have support for hardware breakpoints and users can specify them
with `-H`. However, there's no option to force LLDB to use hardware
breakpoints internally, for example while stepping.
This patch adds a setting target.require-hardware-breakpoint that forces
LLDB to always use hardware breakpoints. Because hardware breakpoints
are a limited resource and can fail to resolve, this patch also extends
error handling in thread plans, where breakpoints are used for stepping.
Differential revision: https://reviews.llvm.org/D54221
llvm-svn: 346920
After committing the initial reproducer feature I noticed a few small
issues which warranted addressing here. It fixes incorrect documentation
in the command object and extract some duplicated code into the debugger
object.
llvm-svn: 346919
This fixes two compilation failures:
1) Designated initializers are C++20. We can't use them in LLVM.
2) thread_result_t is not a pointer type on all platforms, so
returning nullptr is an error.
llvm-svn: 346873
The DataExtractor class itself was moved to Utility some time ago, but
it seems this was not reflected in the location of the test code. Fix
that.
llvm-svn: 346867
Test cases were updated to not use the local compilation dir which
is different between development pc and build bots.
Original commit message:
[LLDB] - Support the single file split DWARF.
DWARF5 spec describes a single file split dwarf case
(when .dwo sections are in the .o files).
Problem is that LLDB does not work correctly in that case.
The issue is that, for example, both .debug_info and .debug_info.dwo
has the same type: eSectionTypeDWARFDebugInfo. And when code searches
section by type it might find the regular debug section
and not the .dwo one.
The patch fixes that. With it, LLDB is able to work with
output compiled with -gsplit-dwarf=single flag correctly.
Differential revision: https://reviews.llvm.org/D52403
llvm-svn: 346855
Summary:
While parsing a childless compile unit DIE we could crash if the DIE was
followed by any extra data (such as a superfluous end-of-children
marker). This happened because the break-on-depth=0 check was performed
only when parsing the null DIE, which was not correct because with a
childless root DIE, we could reach the end of the unit without ever
encountering the null DIE.
If the compile unit contribution ended directly after the CU DIE,
everything would be fine as we would terminate parsing due to reaching
EOF. However, if the contribution contained extra data (perhaps a
superfluous end-of-children marker), we would crash because we would
treat that data as the begging of another compile unit.
This fixes the crash by moving the depth=0 check to a more generic
place, and also adds a regression test.
Reviewers: clayborg, jankratochvil, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D54417
llvm-svn: 346849
Stefan Granitz