summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core
Commit message (Collapse)AuthorAgeFilesLines
* [lldb/DWARF] Move location list sections into DWARFContextPavel Labath2020-01-141-0/+4
| | | | | | These are the last sections not managed by the DWARFContext object. I also introduce separate SectionType enums for dwo section variants, as this is necessary for proper handling of single-file split dwarf.
* [lldb] Remove various dead Compare functionsAlex Langford2020-01-081-23/+0
|
* [lldb][NFC] Use static_cast instead of reinterpret_cast where possibleRaphael Isemann2020-01-071-2/+2
| | | | | | | | | | | | | | Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
* [lldb/CMake] Fix variable naming in FindLibEditJonas Devlieghere2020-01-021-1/+1
| | | | | | | | | | | | The current FOUND_VAR for FindLibEdit is libedit_FOUND but wasn't set by find_package_handle_standard_args. However this isn't valid for the package name. The argument for FOUND_VAR is "libedit_FOUND", but only "LibEdit_FOUND" and "LIBEDIT_FOUND" are valid names. This fixes all the variables set by FindLibEdit to match the desired naming scheme.
* [lldb/ScriptInterpreter] Remove can_reload which is always true (NFC)Jonas Devlieghere2019-12-221-3/+1
| | | | | | The `-r` option for `command script import` is there for legacy compatibility, however the can_reload flag is always set to true. This patch removes the flag and any code that relies on it being false.
* [lldb/Core] Support asking the debugger for a specific script interpreterJonas Devlieghere2019-12-211-7/+11
| | | | | | | | | Rather than holding on to one script interpreter, it should be possible to request a script interpreter for a specific scripting language. The GetScriptInterpreter method now takes an optional scripting language argument. (NFC)
* [lldb] Fix ARM32 inferior callsJan Kratochvil2019-12-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()' Actual: error: Expression can't be run, because there is no JIT compiled function Expected: <nothing, sync() has been executed> This patch has been checked by: D71707: clang-tidy: new bugprone-pointer-cast-widening https://reviews.llvm.org/D71707 Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended: echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out <stdin>: In function ‘main’: <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000 With debug output: Actual: IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3) Code can be run in the target. Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv Sections: [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text) ... HandleCommand, command did not succeed error: Expression can't be run, because there is no JIT compiled function Expected: IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3) IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060]. Code can be run in the target. Found function, has local address 0xb6fac000 and remote address 0xb6ff9020 Function's code range is [0xb6ff9020+0x40] ... Function data has contents: 0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1 ... Function disassembly: 0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr} Differential revision: https://reviews.llvm.org/D71498
* Re-land "[lldb/CMake] Change how we deal with optional dependencies"Jonas Devlieghere2019-12-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently there has been some discussion about how we deal with optional dependencies in LLDB. The approach in LLVM is to make things work out of the box. If the dependency isn't there, we move on silently. That's not true for LLDB. Unless you explicitly disable the dependency with LLDB_ENABLE_*, you'll get a configuration-time error. The historical reason for this is that LLDB's dependencies have a much broader impact, think about Python for example which is required to run the test suite. The current approach can be frustrating from a user experience perspective. Sometimes you just want to ensure LLDB builds with a change in clang. This patch changes the optional dependencies (with the exception of Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On, Off or Auto, with the latter being the default. On and Off behave the same as today, forcing the dependency to be enabled or disabled. If the dependency is set to On but is not found, it results in a configuration time warning. For Auto we detect if the dependency is there and either enable or disable it depending on whether it's found. Differential revision: https://reviews.llvm.org/D71306 PS: The reason Python isn't included yet is because it's so pervasive that I plan on doing that in a separate patch.
* [lldb] Fix an unused variable warningPavel Labath2019-12-201-1/+1
|
* Run all threads when extending a next range over a call.Jim Ingham2019-12-161-2/+9
| | | | | | | | | If you don't do this you end up running arbitrary code with only one thread allowed to run, which can cause deadlocks. <rdar://problem/56422478> Differential Revision: https://reviews.llvm.org/D71440
* [lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHONJonas Devlieghere2019-12-131-1/+1
| | | | | | | This matches the naming scheme used by LLVM and all the other optional dependencies in LLDB. Differential revision: https://reviews.llvm.org/D71482
* [FormatEntity] Add mangled function name supportMed Ismail Bennani2019-12-121-0/+27
| | | | | | | | | | | | | | | | | | Summary: Add `function.mangled-name` key for FormatEntity to show the mangled function names in backtraces. rdar://54088244 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71237 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
* [lldb/Core] Add missing includeJonas Devlieghere2019-12-121-1/+1
| | | | This got flagged by the modules build.
* [lldb/CMake] Rename LLDB_DISABLE_LIBEDIT to LLDB_ENABLE_LIBEDITJonas Devlieghere2019-12-122-18/+18
| | | | | | This matches the naming scheme used by LLVM. Differential revision: https://reviews.llvm.org/D71380
* [lldb/CMake] Rename LLDB_DISABLE_CURSES to LLDB_ENABLE_CURSESJonas Devlieghere2019-12-122-6/+6
| | | | | | This matches the naming scheme used by LLVM. Differential revision: https://reviews.llvm.org/D71377
* [lldb/CMake] Simplify linking against cursesJonas Devlieghere2019-12-111-1/+5
| | | | | | Centralize the logic to determine what libraries to link against for curses in the CMake file where it is actually being used. Use target_include_directories instead of include_directories.
* Remove TypeValidators (NFC in terms of the testsuite)Adrian Prantl2019-12-111-32/+8
| | | | | | | | This is a half-implemented feature that as far as we can tell was never used by anything since its original inclusion in 2014. This patch removes it to make remaining the code easier to understand. Differential Revision: https://reviews.llvm.org/D71310
* [lldb/Host] Use Host/Config.h entries instead of a global define.Jonas Devlieghere2019-12-102-0/+2
| | | | | | | | | | | As suggested by Pavel in a code review: > Can we replace this (and maybe python too, while at it) with a > Host/Config.h entry? A global definition means that one has to > recompile everything when these change in any way, whereas in > practice only a handful of files need this.. Differential revision: https://reviews.llvm.org/D71280
* [lldb] Migrate VMRange::Dump to raw_ostreamRaphael Isemann2019-12-061-1/+1
|
* [lldb][NFC] Migrate FileSpec::Dump to raw_ostreamRaphael Isemann2019-12-063-3/+3
|
* [lldb] NFC: less nesting in SearchFilter.cppKonrad Kleine2019-12-061-165/+170
| | | | | | | | | | | | I was working on SearchFilter.cpp and felt it a bit too complex in some cases in terms of nesting and logic flow. Reviewers: teemperor, JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71022
* [lldb][NFC] Move Address and AddressRange functions out of Stream and let ↵Raphael Isemann2019-12-054-18/+24
| | | | | | | | | | | | | | | | | | | | | | them take raw_ostream Summary: Yet another step on the long road towards getting rid of lldb's Stream class. We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs. I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy. Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71052
* Add a default copy-assignment or copy-constructor for -Wdeprecated-copy ↵Eric Christopher2019-12-041-0/+2
| | | | warnings.
* [lldb] s/FileSpec::Equal/FileSpec::MatchPavel Labath2019-12-044-26/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The FileSpec class is often used as a sort of a pattern -- one specifies a bare file name to search, and we check if in matches the full file name of an existing module (for example). These comparisons used FileSpec::Equal, which had some support for it (via the full=false argument), but it was not a good fit for this job. For one, it did a symmetric comparison, which makes sense for a function called "equal", but not for typical searches (when searching for "/foo/bar.so", we don't want to find a module whose name is just "bar.so"). This resulted in patterns like: if (FileSpec::Equal(pattern, file, pattern.GetDirectory())) which would request a "full" match only if the pattern really contained a directory. This worked, but the intended behavior was very unobvious. On top of that, a lot of the code wanted to handle the case of an "empty" pattern, and treat it as matching everything. This resulted in conditions like: if (pattern && !FileSpec::Equal(pattern, file, pattern.GetDirectory()) which are nearly impossible to decipher. This patch introduces a FileSpec::Match function, which does exactly what most of FileSpec::Equal callers want, an asymmetric match between a "pattern" FileSpec and a an actual FileSpec. Empty paterns match everything, filename-only patterns match only the filename component. I've tried to update all callers of FileSpec::Equal to use a simpler interface. Those that hardcoded full=true have been changed to use operator==. Those passing full=pattern.GetDirectory() have been changed to use FileSpec::Match. There was also a handful of places which hardcoded full=false. I've changed these to use FileSpec::Match too. This is a slight change in semantics, but it does not look like that was ever intended, and it was more likely a result of a misunderstanding of the "proper" way to use FileSpec::Equal. [In an ideal world a "FileSpec" and a "FileSpec pattern" would be two different types, but given how widespread FileSpec is, it is unlikely we'll get there in one go. This at least provides a good starting point by centralizing all matching behavior.] Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: emaste, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70851
* [lldb][NFC] Migrate to raw_ostream in Module::GetDescriptionRaphael Isemann2019-12-041-10/+11
|
* [lldb][NFC] Move Curses interface implementation to own fileRaphael Isemann2019-12-033-4014/+4065
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The IOHandler class source file is currently around 4600 LOC. However only 200 of these lines are concerned with the actual IOHandler class and the rest are the implementations for Editline, IOHandlerConfirm and the Curses interface. All these large features also cause that the IOHandler (which is in Core) has a large set of dependencies on other parts of LLDB. This patch splits out the code for the curses interface into its own file. This way the simple IOHandler code is no longer buried in-between much larger functionalities. Next up is splitting out the other IOHandlers into their own files and then move them to more appropriate parts of LLDB. Reviewers: labath, clayborg, JDevlieghere Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70946
* [lldb][NFC] Remove ThreadSafeSTLVector and ThreadSafeSTLMap and their use in ↵Raphael Isemann2019-12-031-11/+38
| | | | | | | | | | | | | | | | | | | | | | ValueObjectSynthetic Summary: ThreadSafeSTLVector and ThreadSafeSTLMap are not useful for achieving any degree of thread safety in LLDB and should be removed before they are used in more places. They are only used (unsurprisingly incorrectly) in `ValueObjectSynthetic::GetChildAtIndex`, so this patch replaces their use there with a simple mutex with which we guard the related data structures. This doesn't make ValueObjectSynthetic::GetChildAtIndex any more thread-safe, but on the other hand it at least allows us to get rid of the ThreadSafeSTL* data structures without changing the observable behaviour of ValueObjectSynthetic (beside that it is now a few bytes smaller). Reviewers: labath, JDevlieghere, jingham Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70845
* [lldb] Remove FileSpec->CompileUnit inheritancePavel Labath2019-11-295-16/+21
| | | | | | | | | | | | | | | | | | | | | | | Summary: CompileUnit is a complicated class. Having it be implicitly convertible to a FileSpec makes reasoning about it even harder. This patch replaces the inheritance by a simple member and an accessor function. This avoid the need for casting in places where one needed to force a CompileUnit to be treated as a FileSpec, and does not add much verbosity elsewhere. It also fixes a bug where we were wrongly comparing CompileUnit& and a CompileUnit*, which compiled due to a combination of this inheritance and the FileSpec*->FileSpec implicit constructor. Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70827
* [lldb] NFC: refactor CompileUnit::ResolveSymbolContextKonrad Kleine2019-11-281-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I found the above named method hard to read because it had a) many nested blocks, b) one return statement at the end with some logic involved, c) a duplicated while-loop with just small differences in it. I decided to refactor this function by employing an early exit strategy. In order to capture the logic in the return statement and to not have it repeated more than once I chose to implement a very small lamda function that captures all the variables it needs. I also replaced the two while-loops with just one. This is a non-functional change (NFC). Reviewers: jdoerfert, teemperor Reviewed By: teemperor Subscribers: labath, teemperor, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70774
* Revert "[lldb] NFC: refactor CompileUnit::ResolveSymbolContext"Raphael Isemann2019-11-281-3/+4
| | | | | | This reverts commit 373e2a4f69d623e59329ff801f261d8b299e12d2. This broke breakpoint setting.
* [lldb] NFC: refactor CompileUnit::ResolveSymbolContextKonrad Kleine2019-11-281-4/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: I found the above named method hard to read because it had a) many nested blocks and b) one return statement at the end with some logic involved. I decided to refactor this function by employing an early exit strategy. In order to capture the logic in the return statement and to not have it repeated more than once I chose to implement a very small lamda function that captures all the variables it needs. This is a non-functional change (NFC). Reviewers: jdoerfert Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70774
* [lldb] Add boilerplate to recognize the .debug_rnglists.dwo sectionPavel Labath2019-11-261-0/+2
|
* [lldb][NFC] Allow range-based for-loops on VariableListRaphael Isemann2019-11-252-12/+9
| | | | | | | | | | | | | | | | Summary: Adds support for doing range-based for-loops on LLDB's VariableList and modernises all the index-based for-loops in LLDB where possible. Reviewers: labath, jdoerfert Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70668
* Add a testcase for Clang modules being updated within one LLDB session.Adrian Prantl2019-11-151-3/+4
| | | | This actually works as expected, but wasn't explicitly tested before.
* [LLDB] Remove dead code from StreamFileJonas Devlieghere2019-11-131-17/+0
|
* Performance: Add a set of visited SymbolFiles to the other FindFiles variant.Adrian Prantl2019-11-121-3/+5
| | | | | | | | | | | | | | This is basically the same bug as in r260434. SymbolFileDWARF::FindTypes has exponential worst-case when digging through dependency DAG of .pcm files because each object file and .pcm file may depend on an already-visited .pcm file, which may again have dependencies. Fixed here by carrying a set of already visited SymbolFiles around. rdar://problem/56993424 Differential Revision: https://reviews.llvm.org/D70106
* [lldb] Fix more -Wdeprecated-copy warningsPavel Labath2019-11-121-20/+0
| | | | | | | This warning triggers when a class defines a copy constructor but not a copy-assignment operator (which then gets auto-generated by the compiler). Fix the warning by deleting the other operator too, as the default implementation works just fine.
* [LLDB] Fix handling for the clang name mangling extension for block invocationsshafik2019-11-061-15/+23
| | | | | | Add support for clangs mangling extension for block invocations. Differential Revision: https://reviews.llvm.org/D69738
* [ValueObject] Upstream early exit from swift-lldb. (NFC)Adrian Prantl2019-11-051-0/+4
|
* [ValueObject] Upstream initialization from swift-lldb.Adrian Prantl2019-11-051-0/+10
| | | | | | | This is a non-Swift-specific change in swift-lldb that seems to be useful for remote debugging. If does in fact turn out to be redundant we can remove it from llvm.org and then it will disappear in swift-lldb, too.
* ValueObject: Upstream early-exit from swift-lldb. (NFC)Adrian Prantl2019-11-051-3/+8
|
* [lldb] Add trailing dots to comments in Value.cppRaphael Isemann2019-11-041-2/+2
| | | | | | | | | | | | Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: JDevlieghere, lldb-commits Tags: #upstreaming_lldb_s_downstream_patches, #lldb Differential Revision: https://reviews.llvm.org/D69717
* [Symbol] Change ClangASTContext::GetCXXClassName return typeAlex Langford2019-10-311-6/+5
| | | | | | | | | Summary: Instead of filling out a std::string and returning a bool to indicate success, returning a std::string directly and testing to see if it's empty seems like a cleaner solution overall. Differential Revision: https://reviews.llvm.org/D69641
* ValueObject: Fix a crash related to children address type computationPavel Labath2019-10-252-45/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes a crash encountered when debugging optimized code. If some variable has been completely optimized out, but it's value is nonetheless known, the compiler can replace it with a DWARF expression computing its value. The evaluating these expressions results in a eValueTypeHostAddress Value object, as it's contents are computed into an lldb buffer. However, any value that is obtained by dereferencing pointers in this object should no longer have the "host" address type. Lldb had code to account for this, but it was only present in the ValueObjectVariable class. This wasn't enough when the object being described was a struct, as then the object holding the actual pointer was a ValueObjectChild. This caused lldb to dereference the contained pointer in the context of the host process and crash. Though I am not an expert on ValueObjects, it seems to me that this children address type logic should apply to all types of objects (and indeed, applying applying the same logic to ValueObjectChild fixes the crash). Therefore, I move this code to the base class, and arrange it to be run everytime the value is updated. The test case is a reduced and simplified version of the original debug info triggering the crash. Originally we were dealing with a local variable, but as these require a running process to display, I changed it to use a global one instead. Reviewers: jingham, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D69273
* Modernize the rest of the Find.* API (NFC)Adrian Prantl2019-10-175-131/+70
| | | | | | | | | | | | This patch removes the size_t return value and the append parameter from the remainder of the Find.* functions in LLDB's internal API. As in the previous patches, this is motivated by the fact that these parameters aren't really used, and in the case of the append parameter were frequently implemented incorrectly. Differential Revision: https://reviews.llvm.org/D69119 llvm-svn: 375160
* [LLDB] Use the llvm microsoft demangler instead of the windows dbghelp api. ↵Martin Storsjo2019-10-161-41/+7
| | | | | | | | NFCI. Differential Revision: https://reviews.llvm.org/D68134 llvm-svn: 375034
* update ScriptInterpreterPython to use File, not FILE*Lawrence D'Anna2019-10-161-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: ScriptInterpreterPython needs to save and restore sys.stdout and friends when LLDB runs a python script. It currently does this using FILE*, which is not optimal. If whatever was in sys.stdout can not be represented as a FILE*, then it will not be restored correctly when the script is finished. It also means that if the debugger's own output stream is not representable as a file, ScriptInterpreterPython will not be able to redirect python's output correctly. This patch updates ScriptInterpreterPython to represent files with lldb_private::File, and to represent whatever the user had in sys.stdout as simply a PythonObject. This will make lldb interoperate better with other scripts or programs that need to manipulate sys.stdout. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68962 llvm-svn: 374964
* uint32_t options -> File::OpenOptions optionsLawrence D'Anna2019-10-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch re-types everywhere that passes a File::OpenOptions as a uint32_t so it actually uses File::OpenOptions. It also converts some OpenOptions related functions that fail by returning 0 or NULL into llvm::Expected split off from https://reviews.llvm.org/D68737 Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68853 llvm-svn: 374817
* IOHandler: fall back on File::Read if a FILE* isn't available.Lawrence D'Anna2019-10-111-71/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: IOHandler needs to read lines of input from a lldb::File. The way it currently does this using, FILE*, which is something we want to avoid now. I'd prefer to just replace the FILE* code with calls to File::Read, but it contains an awkward and delicate workaround specific to ctrl-C handling on windows, and it's not clear if or how that workaround would translate to lldb::File. So in this patch, we use use the FILE* if it's available, and only fall back on File::Read if that's the only option. I think this is a reasonable approach here for two reasons. First is that interactive terminal support is the one area where FILE* can't be avoided. We need them for libedit and curses anyway, and using them here as well is consistent with that pattern. The second reason is that the comments express a hope that the underlying windows bug that's being worked around will be fixed one day, so hopefully when that happens, that whole path can be deleted. Reviewers: JDevlieghere, jasonmolenda, labath, lanza Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68622 llvm-svn: 374576
* [lldb][NFC] Remove strange bool parameter from Searcher::SearchCallbackRaphael Isemann2019-10-104-17/+14
| | | | | | | | | | | | | | | | | | | Summary: The SearchCallback has a bool parameter that we always set to false, we never use in any callback implementation and that also changes its name from one file to the other (either `containing` and `complete`). It was added in the original LLDB check in, so there isn't any history what this was supposed to be, so let's just remove it. Reviewers: jingham, JDevlieghere, labath Reviewed By: jingham, labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68696 llvm-svn: 374313
OpenPOWER on IntegriCloud