Commit Graph

1052 Commits

Author SHA1 Message Date
Fred Riss 8113a8bb79 [lldb/ObjectFileMachO] Fetch shared cache images from our own shared cache
Summary:
On macOS 11, the libraries that have been integrated in the system
shared cache are not present on the filesystem anymore. LLDB was
using those files to get access to the symbols of those libraries.
LLDB can get the images from the target process memory though.

This has 2 consequences:
 - LLDB cannot load the images before the process starts, reporting
   an error if someone tries to break on a system symbol.
 - Loading the symbols by downloading the data from the inferior
   is super slow. It takes tens of seconds at the start of the
   debug session to populate the Module list.

To fix this, we can use the library images LLDB has in its own
mapping of the shared cache. Shared cache images are somewhat
special as their LINKEDIT segment is moved to the end of the cache
and thus the images are not contiguous in memory. All of this can
hidden in ObjectFileMachO.

This patch fixes a number of test failures on macOS 11 due to the
first problem described above and adds some specific unittesting
for the new SharedCache Host utilities.

Reviewers: jasonmolenda, labath

Subscribers: llvm-commits, lldb-commits

Tags: #lldb, #llvm

Differential Revision: https://reviews.llvm.org/D83023
2020-07-16 10:37:37 -07:00
Pavel Labath f819d25798 [lldb] Delete useless assertion
It served a puprose while we were using the test name to provide a name
for the created file. Now that the files are created in memory, we don't
need that.
2020-07-15 15:42:53 +02:00
Eric Christopher 368eb7712f Fix a -Wunused-variable warning. 2020-07-14 12:40:56 -07:00
Fred Riss a4a00ced0c [lldb/Module] Allow for the creation of memory-only modules
Summary:
This patch extends the ModuleSpec class to include a
DataBufferSP which contains the module data. If this
data is provided, LLDB won't try to hit the filesystem
to create the Module, but use only the data stored in
the ModuleSpec.

Reviewers: labath, espindola

Subscribers: emaste, MaskRay, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D83512
2020-07-14 08:45:44 -07:00
Pavel Labath 1847f4dd75 [lldb/Utility] Rewrite Scalar::SetValueFromCString
The function's reliance on host types meant that it was needlessly
complicated, and did not handle the newer (wider) types. Rewrite it in
terms of APInt/APFloat functions to save code and improve functionality.
2020-07-13 16:44:42 +02:00
Jonas Devlieghere 169c83208f [ldb/Reproducers] Add YamlRecorder and MultiProvider
This patch does several things that are all closely related:

 - It introduces a new YamlRecorder as a counterpart to the existing
   DataRecorder. As the name suggests the former serializes data as yaml
   while the latter uses raw texts or bytes.

 - It introduces a new MultiProvider base class which can be backed by
   either a DataRecorder or a YamlRecorder.

 - It reimplements the CommandProvider in terms of the new
   MultiProvider.

Finally, it adds unit testing coverage for the MultiProvider, a naive
YamlProvider built on top of the new YamlRecorder and the existing
MutliLoader.

Differential revision: https://reviews.llvm.org/D83441
2020-07-10 12:48:22 -07:00
Jonas Devlieghere 5e9b16b67f [lldb] Fix unaligned load in DataExtractor
Somehow UBSan would only report the unaligned load in TestLinuxCore.py
when running the tests with reproducers. This patch fixes the issue by
using a memcpy in the GetDouble and the GetFloat method.

Differential revision: https://reviews.llvm.org/D83256
2020-07-07 10:13:41 -07:00
Pavel Labath 52495b98ee [lldb/Utility] Fix float->integral conversions in Scalar APInt getters
These functions were doing a bitcast on the float value, which is not
consistent with the other getters, which were doing a numeric conversion
(47.0 -> 47). Change these to do numeric conversions too.
2020-07-07 16:59:06 +02:00
Pavel Labath 5daa39aa4c [lldb/Utility] Merge Scalar::Get(Value)TypeAsCString 2020-07-06 10:34:12 +02:00
Pavel Labath b725142c8d [lldb] Fix type conversion in the Scalar getters
Summary:
The Scalar class claims to follow the C type conversion rules. This is
true for the Promote function, but it is not true for the implicit
conversions done in the getter methods.

These functions had a subtle bug: when extending the type, they used the
signedness of the *target* type in order to determine whether to do
sign-extension or zero-extension. This is not how things work in C,
which uses the signedness of the *source* type. I.e., C does
(sign-)extension before it does signed->unsigned conversion, and not the
other way around.

This means that: (unsigned long)(int)-1
      is equal to (unsigned long)0xffffffffffffffff
      and not (unsigned long)0x00000000ffffffff

Unsurprisingly, we have accumulated code which depended on this
inconsistent behavior. It mainly manifested itself as code calling
"ULongLong/SLongLong" as a way to get the value of the Scalar object in
a primitive type that is "large enough". Previously, the ULongLong
conversion did not do sign-extension, but now it does.

This patch makes the Scalar getters consistent with the declared
semantics, and fixes the couple of call sites that were using it
incorrectly.

Reviewers: teemperor, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D82772
2020-07-02 18:02:57 +02:00
Pavel Labath 8270a903ba [lldb] Scalar re-fix UB in float->int conversions
The refactor in 48ca15592f reintroduced UB when converting out-of-bounds
floating point numbers to integers -- the behavior for ULongLong() was
originally fixed in r341685, but did not survive my refactor because I
based my template code on one of the methods which did not have this
fix.

This time, I apply the fix to all float->int conversions, instead of
just the "double->unsigned long long" case. I also use a slightly
simpler version of the code, with fewer round-trips
(APFloat->APSInt->native_int vs
APFloat->native_float->APInt->native_int).

I also add some unit tests for the conversions.
2020-07-01 10:29:42 +02:00
Raphael Isemann bc163f6324 [lldb] Fix TestModuleGetXcodeSDK test after DWARFYAML change
D82622 / fe08ab542b changes the YAML format
so this test was failing as the test yaml wasn't updated.
2020-06-30 14:05:20 +02:00
Xing GUO fe08ab542b [DWARFYAML][debug_info] Replace 'InitialLength' with 'Format' and 'Length'.
'InitialLength' is replaced with 'Format' (DWARF32 by default) and 'Length' in this patch.
Besides, test cases for DWARFv4 and DWARFv5, DWARF32 and DWARF64 is
added.

Reviewed By: jhenderson

Differential Revision: https://reviews.llvm.org/D82622
2020-06-30 16:28:39 +08:00
Jonas Devlieghere f441313464 [lldb/ScriptInterpreter] Fix Windows error C2371: 'pid_t': redefinition
pyconfig.h(194): error C2371: 'pid_t': redefinition; different basic types
PosixApi.h(82): note: see declaration of 'pid_t'
2020-06-25 17:15:29 -07:00
Pavel Labath d0fa52cc37 [lldb] Rewrite Scalar::GetBytes
This function was modifying and returning pointers to static storage,
which meant that any two accesses to different Scalar objects could
potentially race (depending on which types the objects were storing and
the host endianness).

In the new version the user is responsible for providing a buffer into
which this method will store its binary representation. The main caller
(RegisterValue::GetBytes) already has one such buffer handy, so this did
not require any major rewrites.

To make that work, I've needed to mark the RegisterValue value buffer
mutable -- not an ideal solution, but definitely better than modifying
global storage. This could be further improved by changing
RegisterValue::GetBytes to take a buffer too.
2020-06-25 15:31:48 +02:00
Pavel Labath 16e17ca16a [lldb] Refactor Scalar::TruncOrExtendTo
The "type" argument to the function is mostly useless -- the only
interesting aspect of it is signedness. Pass signedness directly and
compute the value of bits and signedness fields -- that's exactly
what the single caller of this function does.
2020-06-24 15:58:33 +02:00
Raphael Isemann 8340fbb9c7 [lldb] Reactivate Objective-C++ plugin
Summary:
Since commit 7b3ef05a37 the Objective-C++ plugin is dead code.
That commit added Objective-C++ to the list of languages for which `Language::LanguageIsCPlusPlus`
returns true. As the C++ language plugin also uses that method to figure out if it is responsible for a
given language, the C++ plugin since then also became the plugin that we found when looking for
a language plugin for Objective-C++. The only real fallout from that is that the source highlighting
for Objective-C++ files never worked as we always found the C++ plugin which refuses to highlight
files with Objective-C++ extensions.

This patch just adds a special exception for Objective-C++ to the list of languages that are governed
by the C++ plugin. Also adds a test that makes sure that we find the right plugin for all C language
types and that the highlighting for `.mm` (Objective-C++) and `.m` (Objective-C) files works.

I didn't revert 7b3ef05a37 as it does make sense to return
true for Objective-C++ from `Language::LanguageIsCPlusPlus` (e.g., we currently check if we care about
ODR violations by doing `if (Language::LanguageIsCPlusPlus(...))` and this should also work for
Objective-C++).

Fixes rdar://64420183

Reviewers: aprantl

Reviewed By: aprantl

Subscribers: mgorny, abidh, JDevlieghere

Differential Revision: https://reviews.llvm.org/D82109
2020-06-19 19:16:46 +02:00
Jonas Devlieghere 64ec505dd4 [lldb] Rename Master/Slave to Primary/Secondary (NFC) 2020-06-15 15:38:28 -07:00
Xing GUO 0431e4bcb2 Recommit "[DWARFYAML][debug_line] Replace `InitialLength` with `Format` and `Length`."
This recommits fcc0c186e9
2020-06-13 23:39:11 +08:00
Jonas Devlieghere 8f9eb70353 [lldb/Test] Fix unit test suffixes and add a CMake error.
Lit will only look for unittest targets ending in `Tests`. Add an error
when the target doesn't have the `Tests` suffix.
2020-06-12 14:18:27 -07:00
Jonas Devlieghere bfea1df9f0 [lldb/Test] Fix unittest name
Lit looks for the Tests prefix in the unit test name.
2020-06-12 14:01:14 -07:00
Ilya Bukonkin 3b43f00629 [lldb] Check if thread was suspended during previous stop added.
Encountered the following situation: Let we started thread T1 and it hit
breakpoint on B1 location. We suspended T1 and continued the process.
Then we started thread T2 which hit for example the same location B1.
This time in a breakpoint callback we decided not to stop returning
false.

Expected result: process continues (as if T2 did not hit breakpoint) its
workflow with T1 still suspended. Actual result: process do stops (as if
T2 callback returned true).

Solution: We need invalidate StopInfo for threads that was previously
suspended just because something that is already inactive can not be the
reason of stop. Thread::GetPrivateStopInfo() may be appropriate place to
do it, because it gets called (through Thread::GetStopInfo()) every time
before process reports stop and user gets chance to change
m_resume_state again i.e if we see m_resume_state == eStateSuspended
it definitely means it was set during previous stop and it also means
this thread can not be stopped again (cos' it was frozen during
previous stop).

Differential revision: https://reviews.llvm.org/D80112
2020-06-11 15:02:46 -07:00
Jonas Devlieghere de019b88dd [lldb/Interpreter] Support color in CommandReturnObject
Color the error: and warning: part of the CommandReturnObject output,
similar to how an error is printed from the driver when colors are
enabled.

Differential revision: https://reviews.llvm.org/D81058
2020-06-09 10:45:45 -07:00
Pavel Labath 731fee8b42 [lldb] Fail evaluation of DWARF expressions with unknown opcodes
Previously, we were simply ignoring them and continuing the evaluation.
This behavior does not seem useful, because the resulting value will
most likely be completely bogus.
2020-06-08 15:52:28 +02:00
Pavel Labath 4c50cf9197 [lldb] Fix YAMLModuleTester for the rename in 67b4afc4 2020-06-08 13:34:03 +02:00
Jaroslav Sevcik 1beffc1888 Support build-ids of other sizes than 16 in UUID::SetFromStringRef
SBTarget::AddModule currently handles the UUID parameter in a very
weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On
the other hand, shorter-than-16-bytes UUIDs are completely ignored. In
this patch, we change the parsing code to handle UUIDs of arbitrary
size.

To support arbitrary size UUIDs in SBTarget::AddModule, this patch
changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We
subtly change the semantics of SetFromStringRef - SetFromStringRef now
only succeeds if the entire input is consumed to prevent some
prefix-parsing confusion. This is up for discussion, but I believe
this is more consistent - we always return false for invalid UUIDs
rather than sometimes truncating to a valid prefix. Also, all the
call-sites except the API and interpreter seem to expect to consume
the entire input.

This also adds tests for adding existing modules 4-, 16-, and 20-byte
build-ids. Finally, we took the liberty of testing the minidump
scenario we care about - removing placeholder module from minidump and
replacing it with the real module.

Reviewed By: labath, friss

Differential Revision: https://reviews.llvm.org/D80755
2020-06-07 10:03:41 +00:00
Adrian Prantl 3d7b926dd1 Move GetXcode*Directory into HostInfo (NFC)
These functions really don't belong into PlatformDarwin, since they
actualy query state of the Host and not of the remote platform.
2020-06-05 11:59:22 -07:00
Jan Kratochvil 476f520a0b [lldb] Fix SLEB128 decoding
Bug 46181 shows SLEB128 0xED9A924C00011151 decoded as 0xffffffff80011151.
        LLDB show a wrong value for function argument
        https://bugs.llvm.org/show_bug.cgi?id=46181

Differential Revision: https://reviews.llvm.org/D81119
2020-06-04 19:41:24 +02:00
Vedant Kumar 4699a7e230 [lldb/StringPrinter] Support strings with invalid utf8 sub-sequences
Support printing strings which contain invalid utf8 sub-sequences, e.g.
strings like "hello world \xfe", instead of bailing out with "Summary
Unavailable".

I took the opportunity here to delete some hand-rolled utf8 -> utf32
conversion code and replace it with calls into llvm's Support library.

rdar://61554346
2020-06-03 12:24:23 -07:00
Andy Yankovsky 798644e0a4 [Scalar] Fix assignment operator for long long.
Summary:
Assignment operator `operator=(long long)` currently allocates `sizeof(long)`.
On some platforms it works as they have `sizeof(long) == sizeof(long long)`,
but on others (e.g. Windows) it's not the case.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D80995
2020-06-03 13:26:25 +02:00
Adrian Prantl a0b674fd7f Fix UB in EmulateInstructionARM64.cpp
This fixes an unhandled signed integer overflow in AddWithCarry() by
using the llvm::checkedAdd() function. Thats to Vedant Kumar for the
suggestion!

<rdar://problem/60926115>

Differential Revision: https://reviews.llvm.org/D80955
2020-06-01 18:11:50 -07:00
Emre Kultursay 7ff2de4f0c Do not list adb devices when a device id is given
Summary:
On Android, this method gets called twice: first when establishing
a host-server connection, then when attaching to a process id.

Each call takes several seconds to finish (especially slower on Windows)
and eliminating the call for the typical case improves latency significantly.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D79586
2020-05-29 11:36:11 +02:00
Raphael Isemann 019bd6485c [lldb] Don't complete ObjCInterfaceDecls in ClangExternalASTSourceCallbacks::FindExternalVisibleDeclsByName
Summary:
For ObjCInterfaceDecls, LLDB iterates over the `methods` of the interface in FindExternalVisibleDeclsByName
since commit ef423a3ba5 .
However, when LLDB calls `oid->methods()` in that function, Clang will pull in all declarations in the current
DeclContext from the current ExternalASTSource (which is again, `ClangExternalASTSourceCallbacks`). The
reason for that is that `methods()` is just a wrapper for `decls()` which is supposed to provide a list of *all*
(both currently loaded and external) decls in the DeclContext.

However, `ClangExternalASTSourceCallbacks::FindExternalLexicalDecls` doesn't implement support for ObjCInterfaceDecl,
so we don't actually add any declarations and just mark the ObjCInterfaceDecl as having no ExternalLexicalStorage.

As LLDB uses the ExternalLexicalStorage to see if it can complete a type with the ExternalASTSource, this causes
that LLDB thinks our class can't be completed any further by the ExternalASTSource
and will from on no longer make any CompleteType/FindExternalLexicalDecls calls to that decl. This essentially
renders those types unusable in the expression parser as they will always be considered incomplete.

This patch just changes the call to `methods` (which is just a `decls()` wrapper), to some ad-hoc `noload_methods`
call which is wrapping `noload_decls()`. `noload_decls()` won't trigger any calls to the ExternalASTSource, so
this prevents that ExternalLexicalStorage will be set to false.

The test for this is just adding a method to an ObjC interface. Before this patch, this unset the ExternalLexicalStorage
flag and put the interface into the state described above.

In a normal user session this situation was triggered by setting a breakpoint in a method of some ObjC class. This
caused LLDB to create the MethodDecl for that specific method and put it into the the ObjCInterfaceDecl.
Also `ObjCLanguageRuntime::LookupInCompleteClassCache` needs to be unable to resolve the type do
an actual definition when the breakpoint is set (I'm not sure how exactly this can happen, but we just
found no Type instance that had the `TypePayloadClang::IsCompleteObjCClass` flag set in its payload in
the situation where this happens. This however doesn't seem to be a regression as logic wasn't changed
from what I can see).

The module-ownership.mm test had to be changed as the only reason why the ObjC interface in that test had
it's ExternalLexicalStorage flag set to false was because of this unintended side effect. What actually happens
in the test is that ExternalLexicalStorage is first set to false in `DWARFASTParserClang::CompleteTypeFromDWARF`
when we try to complete the `SomeClass` interface, but is then the flag is set back to true once we add
the last ivar of `SomeClass` (see `SetMemberOwningModule` in `TypeSystemClang.cpp` which is called
when we add the ivar). I'll fix the code for that in a follow-up patch.

I think some of the code here needs some rethinking. LLDB and Clang shouldn't infer anything about the ExternalASTSource
and its ability to complete the current type form the `ExternalLexicalStorage` flag. We probably should
also actually provide any declarations when we get asked for the lexical decls of an ObjCInterfaceDecl. But both of those
changes are bigger (and most likely would cause us to eagerly complete more types), so those will be follow up patches
and this patch just brings us back to the state before commit ef423a3ba5 .

Fixes rdar://63584164

Reviewers: aprantl, friss, shafik

Reviewed By: aprantl, shafik

Subscribers: arphaman, abidh, JDevlieghere

Differential Revision: https://reviews.llvm.org/D80556
2020-05-27 12:39:24 +02:00
Pavel Labath ba03bcbc4a [lldb] Remove custom DWARF expression printing code
The llvm DWARFExpression dump is nearly identical, but better -- for
example it does print a spurious space after zero-argument expressions.

Some parts of our code (variable locations) have been already switched
to llvm-based expression dumping. This switches the remainder: unwind
plans and some unit tests.
2020-05-25 16:09:25 +02:00
Jonas Devlieghere a67b2faa7c [lldb/Test] Disable APITests.exe on Windows
The generated binary (APITests.exe) is not a valid googletest binary. I
suspect it has something to do with us linking against liblldb.
2020-05-22 13:07:10 -07:00
Dmitri Gribenko 8214eff467 Revert "[lldb/DataFormatter] Check for overflow when finding NSDate epoch"
This reverts commit b783f70a42. This
change had multiple issues which required post-commit fixups, and not
all issues are fixed yet. In particular, the LLDB build bot for ARM is
still broken. There is also an ongoing conversation in the original
phabricator review about whether there is undefined behavior in the
code.
2020-05-20 12:44:19 +02:00
Dmitri Gribenko 0f1195a586 Revert "[lldb/test] Relax NSDate mock test for non-Apple platforms"
This reverts commit fff3a8464d. It is a
follow-up to b783f70a42, which I'm
reverting -- see the explanation in that revert.
2020-05-20 12:44:19 +02:00
Dmitri Gribenko f67f9e86e8 Revert "[lldb/test] Disable NSDate format check under _WIN32"
This reverts commit e3aa4cd9db. It is a
follow-up to b783f70a42, which I'm
reverting -- see the explanation in that revert.
2020-05-20 12:44:19 +02:00
Dmitri Gribenko 23f29b2fcc Revert "Silence warnings around int/float conversions."
This reverts commit 15ee8a3a58. It is a
follow-up to b783f70a42, which I'm
reverting -- see the explanation in that revert.
2020-05-20 12:44:19 +02:00
Dmitri Gribenko 79fcd35c68 Revert "[lldb/test] Move "DataFormatters/Mock.h" to "Plugins/Language/ObjC/Utilities.h""
This reverts commit 82dbf4aca8. It is a
follow-up to b783f70a42, which I'm
reverting -- see the explanation in that revert.
2020-05-20 12:44:18 +02:00
Vedant Kumar 82dbf4aca8 [lldb/test] Move "DataFormatters/Mock.h" to "Plugins/Language/ObjC/Utilities.h"
This addresses some post-commit review feedback from
https://reviews.llvm.org/D80150 by renaming "Mock.h" to something less
misleading, and keeping logic related to the ObjC plugin separate from
the generic DataFormatters library.
2020-05-19 16:09:42 -07:00
Eric Christopher 15ee8a3a58 Silence warnings around int/float conversions. 2020-05-19 10:56:18 -07:00
Vedant Kumar e3aa4cd9db [lldb/test] Disable NSDate format check under _WIN32
Disable the test which attempts to format an NSDate with a date_value of
0 on _WIN32.

When _WIN32 is defined, GetOSXEpoch returns a date that should be in
2001, but after this is passed through timegm (which, afaict isn't
portable?) the result is a date in 1970:

```
lldb-x64-windows-ninja\llvm-project\lldb\unittests\DataFormatter\MockTests.cpp(39): error:       Expected: *formatDateValue(0)
      Which is: "1970-01-01 00:00:00 Pacific Standard Time"
      To be equal to: "2001-01-01 00:00:00 UTC"
```

http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/4520/steps/test/logs/stdio
2020-05-18 16:51:47 -07:00
Vedant Kumar fff3a8464d [lldb/test] Relax NSDate mock test for non-Apple platforms
On Ubuntu, a formatted date prints as "GMT" instead of "UTC", which is
ok.

http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/4520/steps/test/logs/stdio
2020-05-18 16:00:10 -07:00
Vedant Kumar b783f70a42 [lldb/DataFormatter] Check for overflow when finding NSDate epoch
Summary:
Fixes UBSan-reported issues where the date value inside of an
uninitialized NSDate overflows the 64-bit epoch.

rdar://61774575

Reviewers: JDevlieghere, mib, teemperor

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D80150
2020-05-18 13:12:00 -07:00
Levon Ter-Grigoryan 631048e811 Moving executable module symbols parsing to target creation method.
Summary:
In our project we are using remote client-server LLDB configuration.
We want to parse as much debugging symbols as we can before debugger starts attachment to the remote process.
To do that we are passing the path of the local executable module to CreateTarget method at the client.
But, it seems that this method are not parsing the executable module symbols.
To fix this I added PreloadSymbols call for executable module to target creation method.

This patch also fixes a problem where the DynamicLoader would reset a
module when launching the target. We fix it by making sure
Platform::ResolveExecutable returns the module object obtained from the
remote platform.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D78654
2020-05-14 16:54:14 +02:00
Jonas Devlieghere bad61548b2 [Reproducers] Serialize process arguments in ProcessInfo
While debugging why TestProcessList.py failed during passive replay, I
remembered that we don't serialize the arguments for ProcessInfo. This
is necessary to make the test pass and to make platform process list -v
behave the same during capture and replay.

Differential revision: https://reviews.llvm.org/D79646
2020-05-12 11:12:37 -07:00
Lawrence D'Anna 52712d3ff7 Re-land "get rid of PythonInteger::GetInteger()"
This was reverted due to a python2-specific bug.  Re-landing with a fix
for python2.

Summary:
One small step in my long running quest to improve python exception handling in
LLDB.  Replace GetInteger() which just returns an int with As<long long> and
friends, which return Expected types that can track python exceptions

Reviewers: labath, jasonmolenda, JDevlieghere, vadimcn, omjavaid

Reviewed By: labath, omjavaid

Subscribers: omjavaid, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D78462
2020-05-08 10:57:10 -07:00
Adrian Prantl ae920a81ff Add an API to construct an XcodeSDK from an SDK type.
Also, this moves numSDKs out of the actual enum, as to not mess with
the switch-cases-covered warning.

Differential Revision: https://reviews.llvm.org/D79603
2020-05-08 10:47:13 -07:00
Adrian Prantl dec1c94e80 Add a function to detect whether an Xcode SDK supports Swift
Differential Revision: https://reviews.llvm.org/D79535
2020-05-07 11:29:31 -07:00
Adrian Prantl 6e95d51ecf Add an XcodeSDK::GetSDKTypeForTriple function
This is something used in swift-lldb, but of general usefulness.

Differential Revision: https://reviews.llvm.org/D79538

<rdar://problem/62684906>
2020-05-07 11:12:42 -07:00
Adrian Prantl 01fc85dc96 ParseXcodeSDK: Register both the CU module and the SymbolFile module.
For Swift LLDB (but potentially also for module support in Clang-land)
we need a way to accumulate the path remappings produced by
Module::RegisterXcodeSDK(). In order to make this work for
SymbolFileDebugMaps, registering the search path remapping with both
modules is necessary.

Differential Revision: https://reviews.llvm.org/D79384

<rdar://problem/62750529>
2020-05-06 16:46:22 -07:00
Adrian Prantl f0c08b7eac Move the Xcode SDK path caching to HostInfo
When debugging a remote platform, the platform you get from
GetPlatformForArchitecture doesn't inherit from PlatformDarwin.
HostInfoMacOSX seems like the right place to have a global store of
local paths.

Differential Revision: https://reviews.llvm.org/D79364
2020-05-06 13:43:50 -07:00
Adrian Prantl 5935227e11 Add an explicit API to read the Xcode SDK DWARF attribute from compile units
When debugging from a SymbolMap the creation of CompileUnits for the
individual object files is so lazy that RegisterXcodeSDK() is not
invoked at all before the Swift TypeSystem wants to read it. This
patch fixes this by introducing an explicit
SymbolFile::ParseXcodeSDK() call that can be invoked deterministically
before the result is required.

<rdar://problem/62532151+62326862>

https://reviews.llvm.org/D79273
2020-05-06 13:16:16 -07:00
Vedant Kumar c05f35443c [lldb/unittest] Avoid relying on compiler character encoding in unicode test
This is a speculative fix for a unit test failure on a Win/MSVC2017 bot
(http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/16106/steps/test/logs/stdio).
2020-05-05 09:18:35 -07:00
Reid Kleckner 58c7bf246e Update LLDB filespec tests for remove_dots change
It looks like the new implementation is correct, since there were TODOs
here about getting the new behavior.

I am not sure if "C:..\.." should become "C:" or "C:\", though. The new
output doesn't precisely match the TODO message, but it seems
appropriate given the specification of remove_dots and how .. traversals
work at the root directory.
2020-05-04 17:27:16 -07:00
Vedant Kumar a37caebc2d [lldb/DataFormatters] Delete GetStringPrinterEscapingHelper
Summary:
Languages can have different ways of formatting special characters.
E.g. when debugging C++ code a string might look like "\b", but when
debugging Swift code the same string would look like "\u{8}".

To make this work, plugins override GetStringPrinterEscapingHelper.
However, because there's a large amount of subtly divergent work done in
each override, we end up with large amounts of duplicated code. And all
the memory smashers fixed in one copy of the logic (see D73860) don't
get fixed in the others.

IMO the GetStringPrinterEscapingHelper is overly general and hard to
use. I propose deleting it and replacing it with an EscapeStyle enum,
which can be set as needed by each plugin.

A fix for some swift-lldb memory smashers falls out fairly naturally
from this deletion (https://github.com/apple/llvm-project/pull/1046). As
the swift logic becomes really tiny, I propose moving it upstream as
part of this change. I've added unit tests to cover it.

rdar://61419673

Reviewers: JDevlieghere, davide

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77843
2020-05-04 14:06:55 -07:00
Jonas Devlieghere 8539588783 [lldb/CMake] Set the PYTHON_RPATH for the unit tests
The API and Python script interpreter unit tests also link against
Python and therefore need to set the RPATH when applicable.
2020-04-30 11:05:50 -07:00
Pavel Labath f07f2cee9b [lldb/unittest] Adjust CheckIPSupport function to avoid double-consume of llvm::Error
The problem caught by clang-tidy and reported by Tobias Bosch.
2020-04-28 13:35:07 +02:00
Pavel Labath 18e96a31fe [lldb/unittests] Skip IPv6 test on systems which don't have IPv6 configured
Sadly IPv6 is still not present anywhere. The test was attempting to
detect&skip such hosts, but the way it did that (essentially, by calling
getaddrinfo) meant that it only detected hosts which have IPv6 support
completely compiled out. It did not do anything about hosts which have
it compiled in, but lack runtime configuration even for the ::1 loopback
address.

This patch changes the detection logic to use a new method. It does it
by attempting to bind a socket to the appropriate loopback address. That
should ensure the hosts loopback interface is fully set up. In an effort
to avoid silently skipping the test on too many hosts, the test is
fairly strict about the kind of error it expects in these cases -- it
will only skip the test when receiving EADDRNOTAVAIL. If we find other
error codes that can be reasonably returned in these situations, we can
add more of them.

The (small) change in TCPSocket.cpp is to ensure that the code correctly
propagates the error received from the OS.
2020-04-27 17:33:20 +02:00
Adrian Prantl a0919ac080 Invert an #ifdef in XcodeSDKModuleTests.cpp and actually make the test work. 2020-04-24 18:39:40 -07:00
Adrian Prantl 06e4f69b22 Add a getter to retrieve the XcodeSDK from Module and unit-test it. (NFC)
This API is used by swift-lldb.

(Recommit with missing file git-added)
2020-04-24 17:00:34 -07:00
Adrian Prantl af015c1a33 Revert "Add a getter to retrieve the XcodeSDK from Module and unit-test it. (NFC)"
This reverts commit 345df863ce.

(Forgot to git-add the new file)
2020-04-24 16:59:48 -07:00
Adrian Prantl 345df863ce Add a getter to retrieve the XcodeSDK from Module and unit-test it. (NFC)
This API is used by swift-lldb.
2020-04-24 16:51:54 -07:00
Adrian Prantl b9c7e276bd Disable path-sensitive test on Windows. 2020-04-24 15:21:54 -07:00
Adrian Prantl 79feafa514 Add an internal bit to the XcodeSDK class.
For developing the OS itself there exists an "internal" variant of
each SDK. This patch adds support for these SDK directories to the
XcodeSDK class.

Differential Revision: https://reviews.llvm.org/D78675
2020-04-24 12:55:53 -07:00
Raphael Isemann c2fec2fb17 [lldb] Make RNBSocketTest compile again after socket modernization
Commit c9e6b7010c changed the API but didn't update this
macOS-specific test.
2020-04-23 17:00:02 +02:00
Pavel Labath f512b978b0 [lldb/Utility] Improve error_code->Status conversion
Both entities have the notion of error "namespaces". Map the errno
namespace correctly.
2020-04-23 16:12:41 +02:00
Pavel Labath c9e6b7010c [lldb/Host] Modernize some socket functions
return Expected<Socket> instead of a Status object plus a Socket*&
argument.
2020-04-23 14:20:26 +02:00
Muhammad Omair Javaid 478619cf9a Revert "get rid of PythonInteger::GetInteger()"
This reverts commit 7375212172.

This causes multiple test failures on LLDB AArch64 Linux buildbot.
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/3695

Differential Revision: https://reviews.llvm.org/D78462
2020-04-23 04:38:32 +05:00
Jonas Devlieghere e57361c055 [lldb/Host] Remove TaskPool and replace its uses with llvm::ThreadPool
Remove LLDB's TaskPool and replace its uses with LLVM's ThreadPool.

Differential revision: https://reviews.llvm.org/D78337
2020-04-22 09:17:49 -07:00
Lawrence D'Anna 7375212172 get rid of PythonInteger::GetInteger()
Summary:
One small step in my long running quest to improve python exception handling in
LLDB.  Replace GetInteger() which just returns an int with As<long long> and
friends, which return Expected types that can track python exceptions

Reviewers: labath, jasonmolenda, JDevlieghere, vadimcn

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D78462
2020-04-21 16:55:51 -07:00
Jonas Devlieghere e687aa8282 [lldb/Reproducers] Fix passive replay for (char*, size_t) functions.
Several SB API functions return strings using (char*, size_t) output
arguments. During capture, we serialize an empty string for the char*
because the memory can be uninitialized.

During active replay, we have custom replay redirects that ensure that
we don't override the buffer from which we're reading, but rather write
to a buffer on the heap with the given length. This is sufficient for
the active reproducer use case, where we only care about the side
effects of the API calls, not the values actually returned.

This approach does not not work for passive replay because here we
ignore all the incoming arguments, and re-execute the current function
with the arguments deserialized from the reproducer. This means that
these function will update the deserialized copy of the arguments,
rather than whatever was passed in by the SWIG wrapper.

To solve this problem, this patch extends the reproducer instrumentation
to handle this special case for passive replay. We nog ignore the
replayer in the registry and the incoming char pointer, and instead
reinvoke the current method on the deserialized class, and populate the
output argument.

Differential revision: https://reviews.llvm.org/D77759
2020-04-20 13:26:11 -07:00
Jonas Devlieghere e128d53895 [lldb/Test] Don't friend std::make_unique
This wasn't a great idea to begin with, as you can't really rely on the
implementation, but since it also doesn't work with MSVC I've just made
the ctors public.
2020-04-20 11:48:52 -07:00
Jonas Devlieghere 950a8aa165 [lldb/Reproducers] Support new replay mode: passive replay
Support passive replay as proposed in the RFC [1] on lldb-dev and
described in more detail on the lldb website [2].

This patch extends the LLDB_RECORD macros to re-invoke the current
function with arguments deserialized from the reproducer. This relies on
the function being called in the exact same order as during replay. It
uses the same mechanism to toggle the API boundary as during recording,
which guarantees that only boundary crossing calls are replayed.

Another major change is that before this patch we could ignore the
result of an API call, because we only cared about the observable
behavior. Now we need to be able to return the replayed result to the
SWIG bindings.

We reuse a lot of the recording infrastructure, which can be a little
confusing. We kept the existing naming to limit the amount of churn, but
might revisit that in a future patch.

[1] http://lists.llvm.org/pipermail/lldb-dev/2020-April/016100.html
[2] https://lldb.llvm.org/resources/reproducers.html

Differential revision: https://reviews.llvm.org/D77602
2020-04-20 09:41:40 -07:00
Emre Kultursay 1f820fa4fe [lldb] Fix SourceManager::SourceFileCache insertion
Summary:
Lookup and subsequent insert was done using uninitialized
FileSpec object, which caused the cache to be a no-op.

Bug: llvm.org/PR45310

Depends on D76804.

Reviewers: labath, JDevlieghere

Reviewed By: labath

Subscribers: mgorny, jingham, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D76805
2020-04-20 16:25:54 +02:00
Pavel Labath d5c26f871b [lldb/unittests] Better error messages when creating sockets fails
We get failures in SocketTestUtilities on the pre-merge bots. This
might give us a clue as to what's wrong.
2020-04-16 11:59:37 +02:00
Jason Molenda 1cd92e480c Bug where insn-based unwind plans on arm64 could be wrong
Fix a bug where UnwindAssemblyInstEmulation would confuse which
register is used to compute the Canonical Frame Address after it
had branched over a mid-function epilogue (where the CFA reg changes
from $fp to $sp in the process of epiloguing).  Reinstate the
correct CFA register after we forward the unwind rule for branch
targets.  The failure mode was that UnwindAssemblyInstEmulation
would think CFA was set in terms of $sp after one of these epilogues,
and if it sees modifications to $sp after the branch target, it would
change the CFA offset in the unwind rule -- even though the CFA is
defined in terms of $fp and the $sp changes are irrelevant to correct
calculation.

<rdar://problem/60300528>

Differential Revision: https://reviews.llvm.org/D78077
2020-04-14 16:57:25 -07:00
Jonas Devlieghere cc220d4031 [lldb/Test] Use RAII for reproducer instrumentation data in unittest.
Use a RAII object to manage the lifetime of the reproducer
instrumentation data.
2020-04-14 14:46:39 -07:00
Walter Erquinigo cea112f422 [lldb] Fix a typo in a test name
Summary:
Removing the Test prefix from the file name and its usages. The standard is using only Test as a suffix.
This was correctly pointed out in https://reviews.llvm.org/D77444.

Reviewers: labath, clayborg

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77878
2020-04-14 12:18:58 -07:00
Jonas Devlieghere f78fcd6906 [lldb/Test] Rewrite ReproducerInstrumentationTest
The instrumentation unit tests' current implementation uses global
variables to track constructor calls for the instrumented classes during
replay. This is suboptimal because it indirectly relies on how the
reproducer instrumentation is implemented. I found out when adding
support for passive replay and the test broke because we made an extra
(temporary) copy of the instrumented objects.

Additionally, the old approach wasn't very self-explanatory. It took me
a bit of time to understand why we were expecting the number of objects
in the test.

This patch rewrites the test and uses the index-to-object-mapping to
verify the objects created during replay. You can now specify the
expected objects, in order, and whether they should be valid or not. I
find that it makes the tests much easier to understand. More
importantly, this approach is resilient to implementation detail changes
in the instrumentation.
2020-04-10 16:50:44 -07:00
Adrian Prantl 143d507c9f Preserve the owning module information from DWARF in the synthesized AST
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.

This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.

rdar://problem/59634380

Differential Revision: https://reviews.llvm.org/D75488
2020-04-09 11:09:44 -07:00
Pavel Labath 9aa5fbb3af [lldb] Disable the new Communication test on windows
The ConnectionFileDescriptor class on windows does not support
interruption (see the BytesAvailable method). Therefore this test makes
no sense there.
2020-04-09 15:19:24 +02:00
Pavel Labath 769d7041cc Recommit "[lldb/Core] Fix a race in the Communication class"
The synchronization logic in the previous had a subtle bug. Moving of
the "m_read_thread_did_exit = true" into the critical section made it
possible for some threads calling SynchronizeWithReadThread call to get
stuck. This could happen if there were already past the point where they
checked this variable. In that case, they would block on waiting for the
eBroadcastBitNoMorePendingInput event, which would never come as the
read thread was blocked on getting the synchronization mutex.

The new version moves that line out of the critical section and before
the sending of the eBroadcastBitNoMorePendingInput event, and also adds
some comments to explain why the things need to be in this sequence:
- m_read_thread_did_exit = true: prevents new threads for waiting on
  events
- eBroadcastBitNoMorePendingInput: unblock any current thread waiting
  for the event
- Disconnect(): close the connection. This is the only bit that needs to
  be in the critical section, and this is to ensure that we don't close
  the connection while the synchronizing thread is mucking with it.

Original commit message follows:

Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.

However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.

This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.

The fix is to hold the synchronization mutex while closing the
connection.

I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.

The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.

Reviewers: clayborg, JDevlieghere

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77295
2020-04-09 13:39:00 +02:00
Pavel Labath 76975c744d Revert "[lldb/Core] Fix a race in the Communication class"
This reverts commit ebb071345c -- it seems
to introduce a deadlock in some circumstances.
2020-04-09 12:49:56 +02:00
Pavel Labath ebb071345c [lldb/Core] Fix a race in the Communication class
Summary:
Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.

However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.

This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.

The fix is to hold the synchronization mutex while closing the
connection.

I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.

The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.

Reviewers: clayborg, JDevlieghere

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77295
2020-04-09 12:06:47 +02:00
Walter Erquinigo be3f8a8e1b [commands] Support autorepeat in SBCommands
Summary:
This adds support for commands created through the API to support autorepeat.
This covers the case of single word and multiword commands.

Comprehensive tests are included as well.

Reviewers: labath, clayborg

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77444
2020-04-08 10:54:14 -07:00
Adrian Prantl 1e05d7b3d3 Remap the target (Xcode) SDK directory to the host SDK directory.
This is mostly useful for Swift support; it allows LLDB to substitute
a matching SDK it shipped with instead of the sysroot path that was
used at compile time.

The goal of this is to make the Xcode SDK something that behaves more
like the compiler's resource directory, as in that it ships with LLDB
rather than with the debugged program. This important primarily for
importing Swift and Clang modules in the expression evaluator, and
getting at the APINotes from the SDK in Swift.

For a cross-debugging scenario, this means you have to have an SDK for
your target installed alongside LLDB. In Xcode this will always be the
case.

rdar://problem/60640017

Differential Revision: https://reviews.llvm.org/D76471
2020-04-06 15:51:30 -07:00
Kazuaki Ishizaki e9264b746b [lldb] NFC: Fix trivial typo in comments, documents, and messages
Differential Revision: https://reviews.llvm.org/D77460
2020-04-07 01:06:16 +09:00
Jonas Devlieghere d144087c96 [lldb/Support] Treat empty FileSpec as an invalid file.
LLDB relies on empty FileSpecs being invalid files, for example, they
don't exists. Currently this assumption does not always hold during
reproducer replay, because we pass the result of GetPath to the VFS.
This is an empty string, which the VFS converts to an absolute directory
by prepending the current working directory, before looking it up in the
YAML mapping. This means that an empty FileSpec will exist when the
current working directory does. This breaks at least one test
(TestAddDsymCommand.py) when ran from replay.

This patch special cases empty FileSpecs and returns a sensible result
before calling GetPath and forwarding the call.

Differential revision: https://reviews.llvm.org/D77351
2020-04-03 09:29:22 -07:00
Pavel Labath 451741a9d7 [lldb] Change Communication::SetConnection to take a unique_ptr
The function takes ownership of the object. This makes that explicit,
and avoids unowned pointers floating around.
2020-04-02 14:42:25 +02:00
Adrian Prantl 32672b877d Revert "Preserve the owning module information from DWARF in the synthesized AST"
This reverts commit 4354dfbdf5 while investigating bot fallout.
2020-04-01 18:58:11 -07:00
Adrian Prantl 4354dfbdf5 Preserve the owning module information from DWARF in the synthesized AST
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
sets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.

rdar://problem/59634380

Differential Revision: https://reviews.llvm.org/D75488
2020-04-01 17:46:02 -07:00
Med Ismail Bennani f3a7d790df
[lldb/DWARF] Fix evaluator crash when accessing empty stack.
This patch fixes a crash that happens on the DWARF expression evaluator
when trying to access the top of the stack while it's empty.

rdar://60512489

Differential Revision: https://reviews.llvm.org/D77108

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-03-31 17:44:57 +02:00
Med Ismail Bennani e4a778052e Revert "[lldb/DWARF] Fix evaluator crash when accessing empty stack."
This reverts commit e26eece1e2.
2020-03-31 17:44:17 +02:00
Med Ismail Bennani e26eece1e2 [lldb/DWARF] Fix evaluator crash when accessing empty stack.
This patch fixes a crash that happens on the DWARF expression evaluator
when trying to access the top of the stack while it's empty.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-03-31 17:28:15 +02:00
shafik 8016d61e3c [LLDB] CPlusPlusNameParser does not handles templated operator< properly
CPlusPlusNameParser is used in several places on of them is during IR execution and setting breakpoints to pull information C++ like the basename, the context and arguments.

Currently it does not handle templated operator< properly, because of idiosyncrasy is how clang generates debug info for these cases.

It uses clang::Lexer which will tokenize operator<<A::B> into:

tok::kw_operator
tok::lessless
tok::raw_identifier

Later on the parser in ConsumeOperator() does not handle this case properly and we end up failing to parse.

Differential Revision: https://reviews.llvm.org/D76168
2020-03-27 14:46:39 -07:00
Emre Kultursay 57be22fa17 [LLDB] Fix parsing of IPv6 host:port inside brackets
Summary:
When using IPv6 host:port pairs, typically the host is put inside
brackets, such as [2601🔢...:0213]:5555, and the UriParser
can handle this format.

However, the Android infrastructure in LLDB assumes an additional
brackets around the host:port pair, such that the entire host:port
string can be treated as the host (which is used as an Android Serial
Number), and UriParser cannot handle multiple brackets. Parsing
inputs with such extra backets requires searching the closing bracket
from the right.

Test: BracketedHostnameWithPortIPv6 covers the case mentioned above

Reviewers: #lldb, labath

Reviewed By: labath

Subscribers: kwk, shafik, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D76736
2020-03-26 11:35:54 +01:00
Jonas Devlieghere 5ffb30fd6c [lldb/PlatformDarwin] Expose current toolchain and CL tools directory
Expose two methods to find the current toolchain and the current command
line tools directory. These are used by Swift to find the resource
directory.
2020-03-18 15:08:24 -07:00
Jonas Devlieghere 14970669dd [lldb/Test] Add unittest for FileSpec::operator bool() 2020-03-18 15:08:23 -07:00
Med Ismail Bennani db31e2e1e6
[lldb/Target] Support more than 2 symbols in StackFrameRecognizer
This patch changes the way the StackFrame Recognizers match a certain
frame.

Until now, recognizers could be registered with a function
name but also an alternate symbol.
This change is motivated by a test failure for the Assert frame
recognizer on Linux. Depending the version of the libc, the abort
function (triggered by an assertion), could have more than two
signatures (i.e. `raise`, `__GI_raise` and `gsignal`).

Instead of only checking the default symbol name and the alternate one,
lldb will iterate over a list of symbols to match against.

rdar://60386577

Differential Revision: https://reviews.llvm.org/D76188

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-03-18 14:15:58 +01:00
Jonas Devlieghere 7aa28995e8 [lldb/PlatformDarwin] Be more robust in computing the SDK path with xcrun
The current implementation isn't very resilient when it comes to the
output of xcrun. Currently it cannot deal with:

 - Trailing newlines.
 - Leading newlines and errors/warnings before the Xcode path.
 - Xcode not being named Xcode.app.

This extract the logic into a helper in PlatformDarwin and fixes those
issues. It's also the first step towards removing code duplication
between the different platforms and downstream Swift.

Differential revision: https://reviews.llvm.org/D76261
2020-03-17 14:41:45 -07:00
Jonas Devlieghere 0ce3b710b4 [lldb] Add YAML traits for ArchSpec and ProcessInstanceInfo
Add YAML traits for ArchSpec and ProcessInstanceInfo so they can be
serialized for the reproducers.

Differential revision: https://reviews.llvm.org/D76004
2020-03-12 14:38:37 -07:00
Jonas Devlieghere bc9b6b33a0 [lldb/Utility] Add YAML traits for ConstString and FileSpec.
Add YAML traits for the ConstString and FileSpec classes so they can be
serialized as part of ProcessInfo. The latter needs to be serializable
for the reproducers.

Differential revision: https://reviews.llvm.org/D76002
2020-03-12 10:28:21 -07:00
Raphael Isemann e3fc6b3c34 [lldb][NFC] Fix unsigned/signed comparison warning in SymbolFileDWARFTest.cpp
offset_t is unsigned, so if the RHS is signed we get a warning from clang:
    warning: comparison of integers of different signs: 'const unsigned long long' and 'const int'
2020-03-12 15:30:11 +01:00
Luke Drummond 0fa3320931 [lldb] reject `.debug_arange` sections with nonzero segment size
If a producer emits a nonzero segment size, `lldb` will silently read
incorrect values and crash, or do something worse later as the tuple
size is expected to be 2, rather than 3.

Neither LLVM, nor GCC produce segmented aranges, but this dangerous case
should still be checked and handled.

Reviewed by: clayborg, labath
Differential Revision: https://reviews.llvm.org/D75925
Subscribers: lldb-commits
Tags: #lldb
2020-03-12 12:22:50 +00:00
Adrian Prantl cd4c1adabe Add newly-missing include 2020-03-11 19:30:53 -07:00
Unnar Freyr Erlendsson 594130db0a Add unit tests for RangeDataVector::FindEntryIndexesThatContain
Summary: This adds unit tests for FindEntryIndexesThatContain, this is done in preparation for changing the logic of the function.

Reviewers: labath, teemperor

Reviewed By: labath

Subscribers: arphaman, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D75180
2020-02-26 16:47:42 +01:00
Pavel Labath d4eca120ac [lldb/gdb-remote] Add support for the qOffsets packet
Summary:
This packet is necessary to make lldb work with the remote-gdb stub in
user mode qemu when running position-independent binaries. It reports
the relative position (load bias) of the loaded executable wrt. the
addresses in the file itself.

Lldb needs to know this information in order to correctly set the load
address of the executable. Normally, lldb would be able to find this out
on its own by following the breadcrumbs in the process auxiliary vector,
but we can't do this here because qemu does not support the
qXfer:auxv:read packet.

This patch does not implement full scope of the qOffsets packet (it only
supports packets with identical code, data and bss offsets), because it
is not fully clear how should the different offsets be handled and I am
not aware of a producer which would make use of this feature (qemu will
always
<https://github.com/qemu/qemu/blob/master/linux-user/elfload.c#L2436>
return the same value for code and data offsets). In fact, even gdb
ignores the offset for the bss sections, and uses the "data" offset
instead.  So, until the we need more of this packet, I think it's best
to stick to the simplest solution possible. This patch simply rejects
replies with non-uniform offsets.

Reviewers: clayborg, jasonmolenda

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D74598
2020-02-26 10:18:58 +01:00
Ayke van Laethem ec1efe7113
[LLDB] Let DataExtractor deal with two-byte addresses
AVR usually uses two byte addresses. By making DataExtractor deal with
this, it is possible to load AVR binaries that don't have debug info
associated with them.

Differential Revision: https://reviews.llvm.org/D73969
2020-02-25 16:27:38 +01:00
Raphael Isemann defd0e24aa [lldb][NFC] Move NameSearchContext to own header/source files
The class is large enough to be in its own file. This patch also removes the cyclic
dependency between ClangASTSource <-> NameSearchContext.
2020-02-25 12:25:36 +01:00
Raphael Isemann 3f0661b5e7 [lldb][NFC] Fix compilation of SymbolFilePDBTests.cpp after FindNamespace API change
Since f9568a9549 this function takes a
CompilerDeclContext reference instead of a pointer. It overlooked this function
when I fixed the compilation for FindTypes.
2020-02-18 11:25:12 +01:00
Raphael Isemann 7d13812329 [lldb] Fix compilation of SymbolFilePDBTests.cpp after FindTypes API change
Since f9568a9549 this function takes a
CompilerDeclContext reference instead of a pointer.
2020-02-18 10:52:02 +01:00
Raphael Isemann 8ffea27ae4 [lldb] Refactor and test TypeSystemClang::GetEnumerationIntegerType 2020-02-18 09:52:49 +01:00
Jonas Devlieghere cdc514e4c6 [lldb] Update header guards to be consistent and compliant with LLVM (NFC)
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.

Differential revision: https://reviews.llvm.org/D74743
2020-02-17 23:15:40 -08:00
Jonas Devlieghere 478c9cc4f5 [lldb/Plugins] Rename lldbPluginDisassemblerLLVM (NFC) 2020-02-17 19:14:01 -08:00
Jonas Devlieghere 50c9cd9526 Revert "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin"
This is still failing spectacularly on the Windows bot and I still have
no clue what's going on.
2020-02-17 19:04:50 -08:00
Jonas Devlieghere 9b12dc98fd Re-land "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin"
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.

The previously landed patch got reverted because it was lacking:

 (1) A plugin definition for the Objective-C language runtime,
 (2) The dependency between the Static and WASM dynamic loader,
 (3) Explicit initialization of ScriptInterpreterNone for lldb-test.

All issues have been addressed in this patch.

Differential revision: https://reviews.llvm.org/D73067
2020-02-17 14:43:05 -08:00
Jonas Devlieghere 058cb1b47f Revert "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin"
This temporarily reverts commit 7d6da329de
because it's causing test failures on the bots.
2020-02-17 12:34:21 -08:00
Jonas Devlieghere 7d6da329de [lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.

Differential revision: https://reviews.llvm.org/D73067
2020-02-17 09:07:00 -08:00
Pavel Labath 67f63f3f7c [lldb/DWARF] Re-enable basic dwp support
Summary:
This patch removes the bitrotted SymbolFileDWARF(Dwo)Dwp classes, and
replaces them with dwp support implemented directly inside
SymbolFileDWARFDwo, in a manner mirroring the implementation in llvm.
This patch does:
- add support for the .debug_cu_index section to our DWARFContext
- adds a llvm::DWARFUnitIndex argument to the DWARFUnit constructors.
  This argument is used to look up the offsets of the debug_info and
  debug_abbrev contributions in the sections of the dwp file.
- makes sure the creation of the DebugInfo object as well as the initial
  discovery of DWARFUnits is thread-safe, as we can now call this
  concurrently when doing parallel indexing.

This patch does not:
- use the DWARFUnitIndex to search for other kinds of contributions
  (debug_loc, debug_ranges, etc.). This means that units which reference
  these sections will not work correctly. These will be handled by
  follow-up patches, but even the present level of support is sufficient
  to enable basic functionality.
- Make the llvm::DWARFContext thread-safe. Right now, it just avoids this
  problem by ensuring everything is initialized ahead of time. However,
  this is something we will run into more often as we try to use more of
  llvm, and so I plan to start looking into our options here.

Reviewers: JDevlieghere, aprantl, clayborg

Subscribers: mgorny, mgrang, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73783
2020-02-17 14:10:36 +01:00
Pavel Labath 07355c1c08 [lldb] Delete register info definitions in the x86_64 ABI classes
Summary:
These definitions are used to "augment" information received from the remote
target with eh/debug frame and "generic" register numbers.

Besides being verbose, this information was also incomplete (new registers like
xmm16-31 were missing) and sometimes even downright wrong (ymm register
numbers).

Most of this information is available via llvm's MCRegisterInfo. This patch
creates a new class, MCBasedABI, which retrieves the eh and debug frame register
numbers this way. The tricky part here is that the llvm class uses all-caps
register names, whereas lldb register are lowercase, and sometimes called
slightly differently. Therefore this class introduces some hooks to allow a
subclass to customize the MC lookup. The subclass also needs to suply the
"generic" register numbers, as this is an lldb invention.

This patch ports the x86_64 ABI classes to use the new register info mechanism.
It also creates a new "ABIx86_64" class which can be used to house code common
to x86_64 both ABIs. Right now, this just consists of a single function, but
there are plenty of other things that could be moved here too.

Reviewers: JDevlieghere, jasonmolenda

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D74244
2020-02-17 14:01:36 +01:00
Raphael Isemann 651936e5b6 [lldb][NFC] Remove Stream::Indent(const char *) overload in favor of the StringRef version 2020-02-11 13:29:32 +01:00
Pavel Labath 363f05b83d [lldb] Delete the SharingPtr class
Summary:
The only use of this class was to implement the SharedCluster of ValueObjects.
However, the same functionality can be implemented using a regular
std::shared_ptr, and its little-known "sub-object pointer" feature, where the
pointer can point to one thing, but actually delete something else when it goes
out of scope.

This patch reimplements SharedCluster using this feature --
SharedClusterPointer::GetObject now returns a std::shared_pointer which points
to the ValueObject, but actually owns the whole cluster. The only change I
needed to make here is that now the SharedCluster object needs to be created
before the root ValueObject. This means that all private ValueObject
constructors get a ClusterManager argument, and their static Create functions do
the create-a-manager-and-pass-it-to-value-object dance.

Reviewers: teemperor, JDevlieghere, jingham

Subscribers: mgorny, jfb, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D74153
2020-02-11 13:23:18 +01:00
Med Ismail Bennani cb0c4ee3eb [lldb/test] Add alternate symbol to StackFrame Recognizer
This reimplements commit 6b2979c123 and updates
the tests to reflect the addition of the alternate symbol attribute.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-02-11 11:44:37 +01:00
Raphael Isemann 5b61f78ad5 [lldb] Add test for lldb_private::Stream's indentation functionality 2020-02-11 11:12:54 +01:00
Davide Italiano 6b2979c123 Revert "[lldb] Fix+re-enable Assert StackFrame Recognizer on Linux"
This reverts commit 1a39f1b966 as
it breaks macOS.
2020-02-10 13:27:35 -08:00
Jan Kratochvil 1a39f1b966 [lldb] Fix+re-enable Assert StackFrame Recognizer on Linux
D73303 was failing on Fedora Linux and so it was disabled by Skip the
AssertFrameRecognizer test for Linux.

I find no easy way how to find out if it gets recognized as
`__assert_fail` or `__GI___assert_fail` as during `Process` ctor
libc.so.6 is not yet loaded by the debuggee.

DWARF symbol `__GI___assert_fail` overrides the ELF symbol `__assert_fail`.
While external debug info (=DWARF) gets disabled for testsuite (D55859)
that sure does not apply for real world usage.

Differential Revision: https://reviews.llvm.org/D74252
2020-02-10 10:29:32 +01:00
Med Ismail Bennani 047c4b0369 [lldb/Target] Fix `frame recognizer list` crash when registered with nullptr
One way to register a recognizer is to use RegularExpressionSP for the
module and symbol.

In order to match a symbol regardless of the module, the recognizer can
be registered with a nullptr for the module. However, this cause the
frame recognizer list command to crash because it calls
RegularExpression::GetText without checking if the shared pointer is valid.

This patch adds checks for the symbol and module RegularExpressionSP.

Differential Revision: https://reviews.llvm.org/D74212

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-02-07 17:35:29 +01:00
Alex Langford 7c9ebdd3d6 [lldb] Remove clang classes from lldb-forward.h
Summary:
lldb-forward.h is convenient in many ways, but having clang-based
class forward declarations in there makes it easy to proliferate uses of clang
outside of plugins. Removing them makes you much more conscious of when
you're using something from clang and marks where we're using things
from clang in non-plugins.

Differential Revision: https://reviews.llvm.org/D73935
2020-02-04 14:23:58 -08:00
Jonas Devlieghere c21b71c1ba [lldb/Unittest] Fix the modules build by including TypeSystemClang.h
This should fix the modules build on the GreenDragon bot.
2020-02-04 14:05:15 -08:00
Jonas Devlieghere f37b62ecce Re-land "[lldb] [testsuite] generalize `DWARFASTParserClangTests` based on `DWARFExpressionTest`'s YAML" 2020-02-04 13:59:29 -08:00
Jan Kratochvil b73f8c53d8 Revert: [lldb] [testsuite] generalize `DWARFASTParserClangTests` based on `DWARFExpressionTest`'s YAML
It is causing a failure on OSX, to be investigated more.

Differential Revision: https://reviews.llvm.org/D73279
2020-02-04 22:48:27 +01:00
Jan Kratochvil 104800084f [lldb] [testsuite] Fixup: generalize `DWARFASTParserClangTests` based on `DWARFExpressionTest`'s YAML
The testcase did not compile now because of an upstream change in the
meantime.

For: https://reviews.llvm.org/D73279
2020-02-04 15:03:09 +01:00
Jan Kratochvil 2926a651ba [lldb] [testsuite] generalize `DWARFASTParserClangTests` based on `DWARFExpressionTest`'s YAML
YAMLModuleTester from DWARFExpressionTest can be reused for more
testcases.

Differential Revision: https://reviews.llvm.org/D73279
2020-02-04 14:33:29 +01:00
Vedant Kumar 7b90cdedd1 [lldb/DataExtractor] Fix UB shift in GetMaxS64Bitfield
DataExtractor::GetMaxS64Bitfield performs a shift with UB in order to
construct a bitmask when bitfield_bit_size is 64. The current
implementation actually does “work” in this case, because the assumption
that the shift result is 0 holds, and 0 minus 1 gives the all-ones value
(the correct mask). However, the more readable/maintainable approach
might be to use an off-the-shelf UB-free helper.

Fixes a UBSan issue:

  "col" : 37,
  "description" : "invalid-shift-exponent",
  "filename" : "/Users/vsk/src/llvm-project-master/lldb/source/Utility/DataExtractor.cpp",
  "instrumentation_class" : "UndefinedBehaviorSanitizer",
  "line" : 615,
  "memory_address" : 0,
  "summary" : "Shift exponent 64 is too large for 64-bit type 'uint64_t' (aka 'unsigned long long')",

rdar://59117758

Differential Revision: https://reviews.llvm.org/D73913
2020-02-03 15:57:32 -08:00
Jonas Devlieghere c62ffb1b19 [lldb/Reproducers] Include string length in string (de)serialization.
This allows us to differentiate between an empty string and a nullptr.

(cherry picked from commit 53e206284fa715886020d6a5553bf791582850a3)
2020-01-31 17:40:49 -08:00
Alex Langford 8be30215fe [lldb] Move clang-based files out of Symbol
Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h

This explicitly removes knowledge of clang internals from lldbSymbol,
moving towards a more generic core implementation of lldb.

Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik

Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73661
2020-01-31 12:20:10 -08:00
Pavel Labath 33f65f393f [lldb] Add a basic unit test for the SharedCluster class 2020-01-31 15:46:41 +01:00
Alex Langford 22b044877d [lldb][NFCI] Remove unused LanguageType parameters
These parameters are unused in these methods, and some of them only had a
LanguageType parameter to pipe to other methods that don't use it
either.
2020-01-30 21:57:23 -08:00
Jonas Devlieghere e28d8f9069 [lldb] Replace SmallStr.str().str() with std::string conversion operator.
Use the std::string conversion operator introduced in
d7049213d0. The SmallString in the log
statement doesn't require conversion at all when using the variadic log
macro.
2020-01-29 21:34:19 -08:00
Jonas Devlieghere 91f863be4f [lldb/Reproducers] Add unittest for char** (de)serializer 2020-01-29 17:16:31 -08:00
Raphael Isemann ab8b22d1c2 [lldb] Don't create duplicate declarations when completing a forward declaration with a definition from another source
Summary:
I noticed this strange line in `ASTImporterDelegate::ImportDefinitionTo` which doesn't make a lot of sense:
```
to_tag->setCompleteDefinition(from_tag->isCompleteDefinition());
```

It forcibly sets the imported TagDecl to be defined if the source TagDecl was defined. This doesn't make any
sense as in this code we already forced the ASTImporter to import the definition so this should always be
a no-op.

Turns out this is hiding two bugs:
1. The way we handle forward declarations in the debug info that might be completed later is that we
  import them and then mark them as having external lexical storage. This makes Clang ask for the definition
  later when it needs it (at which point we hopefully have the definition around and can complete it). However,
  this is currently not completing the forward decls with external storage but instead creates a duplicated decl
  in the target AST which is then defined. The forward decl is kept incomplete after the import and we just
  forcibly make it a definition of the record without any content with our workaround. The TestSharedLib* tests
  is only passing because of this.
2. Minimal import of lambdas is broken and never imports the definition it seems. That appears to be a bug
  in the ASTImporter which gives the definition of lambda's some special treatment. TestLambdas.py is actually
  broken but is passing because of this workaround.

This patch fixes the first bug by forcing the ASTImporter to import to the target forward declaration. We can't
delete the workaround as the second bug is still around but that will be a follow up review for the ASTImporter.
However it will get rid of all the duplicated RecordDecls that are in our expression AST that are strangely defined
but don't have any of the fields they are supposed to have.

Reviewers: shafik, labath

Reviewed By: shafik

Subscribers: aprantl, abidh, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73345
2020-01-29 09:20:47 +01:00
Benjamin Kramer 777180a32b [ADT] Make StringRef's std::string conversion operator explicit
This has the same behavior as converting std::string_view to
std::string. This is an expensive conversion, so explicit conversions
are helpful for avoiding unneccessary string copies.
2020-01-28 23:47:07 +01:00
Benjamin Kramer adcd026838 Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 23:25:25 +01:00
Raphael Isemann 243f52b58b [lldb] Cut off unused suffix in CompletionRequest::GetRawLine
The GetRawLine currently returns the full command line used
to create the CompletionRequest. So for example for "foo b[tab] --arg"
it would return the whole string instead of "foo b". Usually
completion code makes the wrong assumption that the cursor is at
the end of the line and handing out the complete line will cause
that people implement completions that also make this assumption.

This patch makes GetRawLine() return only the string until the
cursor and hides the suffix (so that the cursor is always at the
end of this string) and adds another function GetRawLineWithUnusedSuffix
that is specifically the line with the suffix that isn't used by
the CompletionRequest for argument parsing etc.

There is only one user of this new function that actually needs the
suffix and that is the expression command which needs the suffix to
detect if it is in the raw or argument part of the command (by looking
at the "--" separator).
2020-01-28 11:12:22 +01:00
Raphael Isemann 808142876c [lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:52:55 +01:00
Raphael Isemann 6e3b0cc2fb [lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).

I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.

Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai

Reviewed By: clayborg, labath, xiaobai

Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:09:14 +01:00
Raphael Isemann c9a39a896c [lldb] Add a display name to ClangASTContext instances
Summary:
I often struggle to understand what exactly LLDB is doing by looking at our expression evaluation logging as our messages look like this:
```
CompleteTagDecl[2] on (ASTContext*)0x7ff31f01d240 Completing (TagDecl*)0x7ff31f01d568 named DeclName1
```

From the log messages it's unclear what this ASTContext is. Is it the scratch context, the expression context, some decl vendor context or a context from a module?
The pointer value isn't helpful for anyone unless I'm in a debugger where I could inspect the memory at the address. But even with a debugger it's not easy to
figure out what this ASTContext is without having deeper understanding about all the different ASTContext instances in LLDB (e.g., valid SourceLocation
from the file system usually means that this is the Objective-C decl vendor, a file name from multiple expressions is probably the scratch context, etc.).

This patch adds a name field to ClangASTContext instances that we can use to store a name which can be used for logging and debugging. With this
our log messages now look like this:
```
CompleteTagDecl[2] on scratch ASTContext. Completing (TagDecl*)0x7ff31f01d568 named Foo
```
We can now also just print a ClangASTContext from the debugger and see a useful name in the `m_display_name` field, e.g.
```
  m_display_name = "AST for /Users/user/test/main.o";
```

Reviewers: shafik, labath, JDevlieghere, mib

Reviewed By: shafik

Subscribers: clayborg, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D72391
2020-01-22 08:54:10 +01:00
Jonas Devlieghere be9604247e [lldb/Plugin] Move DisassemblerLLVMC for consistency with plugin (NFC)
Rename the DisassemblerLLVMC directory from llvm to LLVMC to match the
plugin name.
2020-01-21 15:17:29 -08:00