summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/PluginManager.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [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
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-56/+31
| | | | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> This reapplies r369690 with a previously missing constructor for LanguageSet. llvm-svn: 369710
* Revert Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-31/+56
| | | | | | This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f) llvm-svn: 369702
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-221-56/+31
| | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> llvm-svn: 369690
* [lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and ↵Raphael Isemann2019-08-221-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | remove any undocumented/redundant return values Summary: We still have some leftovers of the old completion API in the internals of LLDB that haven't been replaced by the new CompletionRequest. These leftovers are: * The return values (int/size_t) in all completion functions. * Our result array that starts indexing at 1. * `WordComplete` mode. I didn't replace them back then because it's tricky to figure out what exactly they are used for and the completion code is relatively untested. I finally got around to writing more tests for the API and understanding the semantics, so I think it's a good time to get rid of them. A few words why those things should be removed/replaced: * The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t. Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does). * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do). * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we `WordComplete` is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get). This patch essentially removes `WordComplete` mode and makes the result array indexed from 0. It also removes all return values from all internal completion functions. The only non-redundant information they contain is about rewriting the current line (which is broken), so that functionality was moved to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)` to do the same. For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we didn't even implement them in the Editline handler (e.g. -1). I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code, but I would prefer doing this in follow-up NFC commits Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66536 llvm-svn: 369624
* [Target] Decouple ObjCLanguageRuntime from LanguageRuntimeAlex Langford2019-06-211-1/+13
| | | | | | | | | | | | Summary: ObjCLanguageRuntime was being pulled into LanguageRuntime because of Breakpoint Preconditions. If we move BreakpointPrecondition out of Breakpoint, we can extend the LanguageRuntime plugin interface so that LanguageRuntimes can give us a BreakpointPrecondition for exceptions. Differential Revision: https://reviews.llvm.org/D63181 llvm-svn: 364098
* [ScriptInterpreter] Pass the debugger instead of the command interpreterJonas Devlieghere2019-04-261-4/+5
| | | | | | | | | | | | | | | | As discussed in D61090, there's no good reason for the script interpreter to depend on the command interpreter. When looking at the code, it becomes clear that we mostly use the command interpreter as a way to access the debugger. Hence, it makes more sense to just pass that to the script interpreter directly. This is part 1 out of 2. I have another patch in the pipeline that changes the ownership of the script interpreter to the debugger as well, but I didn't get around to finish that today. Differential revision: https://reviews.llvm.org/D61172 llvm-svn: 359330
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* Pass ConstString by value (NFC)Adrian Prantl2019-03-061-72/+72
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [lldb] Fix "code requires global destructor" warning in g_architecture_mutexKuba Mracek2018-11-121-4/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D44060 llvm-svn: 346673
* Remove comments after header includes.Jonas Devlieghere2018-11-111-9/+9
| | | | | | | | | | This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. Differential revision: https://reviews.llvm.org/D54385 llvm-svn: 346625
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-2/+2
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* [FileSystem] Remove Exists() from FileSpecJonas Devlieghere2018-11-011-2/+4
| | | | | | | | | This patch removes the Exists method from FileSpec and updates its uses with calls to the FileSystem. Differential revision: https://reviews.llvm.org/D53845 llvm-svn: 345854
* [FileSystem] Move EnumerateDirectory from FileSpec to FileSystem.Jonas Devlieghere2018-11-011-11/+14
| | | | | | | | | | | | | | This patch moves the EnumerateDirectory functionality and related enum and typedef from FileSpec to FileSystem. This is part of a set of patches that extracts file system related convenience methods from FileSpec. The long term goal is to remove this method altogether and use the iterators directly, but for introducing the VFS into LLDB this change is sufficient. Differential revision: https://reviews.llvm.org/D53785 llvm-svn: 345800
* Replace HostInfo::GetLLDBPath with specific functionsPavel Labath2018-06-191-3/+2
| | | | | | | | | | | | | | | | | | | | | Summary: Instead of a function taking an enum value determining which path to return, we now have a suite of functions, each returning a single path kind. This makes it easy to move the python-path function into a specific plugin in a follow-up commit. All the users of GetLLDBPath were converted to call specific functions instead. Most of them were hard-coding the enum value anyway, so this conversion was simple. The only exception was SBHostOS, which I've changed to use a switch on the incoming enum value. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48272 llvm-svn: 335052
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-17/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* s/LLVM_ON_WIN32/_WIN32/, lldbNico Weber2018-04-101-1/+1
| | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. llvm-svn: 329697
* Move StopInfoOverride callback to the new architecture pluginPavel Labath2017-10-251-0/+48
| | | | | | | | | | | | | | | This creates a new Architecture plugin and moves the stop info override callback to this place. The motivation for this is to remove complex dependencies from the ArchSpec class because it is used in a lot of places that (should) know nothing about Process instances and StopInfo objects. I also add a test for the functionality covered by the override callback. Differential Revision: https://reviews.llvm.org/D31172 llvm-svn: 316609
* Rename Error -> Status.Zachary Turner2017-05-121-5/+5
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* iwyu fixes for lldbCore.Zachary Turner2017-04-061-19/+32
| | | | | | | | | | | | | | This adjusts header file includes for headers and source files in Core. In doing so, one dependency cycle is eliminated because all the includes from Core to that project were dead includes anyway. In places where some files in other projects were only compiling due to a transitive include from another header, fixups have been made so that those files also include the header they need. Tested on Windows and Linux, and plan to address failures on OSX and FreeBSD after watching the bots. llvm-svn: 299714
* Move FileSpec from Host -> Utility.Zachary Turner2017-03-221-1/+1
| | | | llvm-svn: 298536
* Resubmit FileSystem changes.Zachary Turner2017-03-081-7/+6
| | | | | | | | | | This was originall reverted due to some test failures in ModuleCache and TestCompDirSymlink. These issues have all been resolved and the code now passes all tests. Differential Revision: https://reviews.llvm.org/D30698 llvm-svn: 297300
* Revert "Use LLVM for all stat-related functionality."Pavel Labath2017-03-071-6/+7
| | | | | | | | | | | | | | | this reverts r297116 because it breaks the unittests and TestCompDirSymlink. The ModuleCache unit test is trivially fixable, but the CompDirSymlink failure is a symptom of a deeper problem: llvm's stat functionality is not a drop-in replacement for lldb's. The former is based on stat(2) (which does symlink resolution), while the latter is based on lstat(2) (which does not). This also reverts subsequent build fixes (r297128, r297120, 297117) and r297119 (Remove FileSpec dependency on FileSystem) which builds on top of this. llvm-svn: 297139
* Use LLVM for all stat-related functionality.Zachary Turner2017-03-071-7/+6
| | | | | | | | | | This deletes LLDB's FileType enumeration and replaces all users, and all calls to functions that check whether a file exists etc with corresponding calls to LLVM. Differential Revision: https://reviews.llvm.org/D30624 llvm-svn: 297116
* Reapply "Refactor log channel registration mechanism"Pavel Labath2017-02-171-87/+0
| | | | | | | | | Changes wrt. previous version: - add #include <atomic>: fix build on windows - add extra {} around the string literals used to initialize llvm::StringLiteral: fix gcc build llvm-svn: 295442
* Revert "Refactor log channel registration mechanism"Pavel Labath2017-02-151-0/+87
| | | | | | | The change breaks on Windows and NetBSD bots. Revert while I investigate. llvm-svn: 295201
* Refactor log channel registration mechanismPavel Labath2017-02-151-87/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We currently have two log channel registration mechanisms. One uses a set of function pointers and the other one is based on the PluginManager. The PluginManager dependency is unfortunate, as logging is also used in lldb-server, and the PluginManager pulls in a lot of classes which are not used in lldb-server. Both approach have the problem that they leave too much to do for the user, and so the individual log channels end up reimplementing command line argument parsing, category listing, etc. Here, I replace the PluginManager-based approach with a one. The new API is more declarative, so the user only needs to specify the list of list of channels, their descriptions, etc., and all the common tasks like enabling/disabling categories are hadled by common code. I migrate the LogChannelDWARF (only user of the PluginManager method) to the new API. In the follow-up commits I'll replace the other channels with something similar. Reviewers: clayborg, zturner, beanz Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D29895 llvm-svn: 295190
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Convert AutoComplete related code to StringRef.Zachary Turner2016-11-171-11/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D26721 llvm-svn: 287188
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-2629/+2042
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-191-0/+173
| | | | | | | | | | | | Take 2, with missing cmake line fixed. Build tested on Ubuntu 14.04 with clang-3.6. See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279202
* Revert "Add StructuredData plugin type; showcase with new DarwinLog feature"Todd Fiala2016-08-191-173/+0
| | | | | | This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8. llvm-svn: 279200
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-191-0/+173
| | | | | | | | | See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279198
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-181-184/+184
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; ↵Eugene Zelenko2016-03-111-262/+176
| | | | | | other minor fixes. llvm-svn: 263300
* Fixed version of r250913, which actually implements all the static functions.Sean Callanan2015-10-211-1/+33
| | | | | | Thanks to Siva Chandra and Oleksiy Vyalov for pouncing on this. llvm-svn: 250928
* Revert "Made the REPL choose a default language if only one REPL can be chosen."Siva Chandra2015-10-211-4/+1
| | | | | | | | | | | | Summary: This reverts commit babd6dd74e316b1fcd9d171d7d8c83845d51a487. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13952 llvm-svn: 250927
* Made the REPL choose a default language if only one REPL can be chosen.Sean Callanan2015-10-211-1/+4
| | | | | | This requires REPLs to enumerate the languages they support. llvm-svn: 250913
* Added the concept of a Read-Eval-Print-Loop to LLDB.Sean Callanan2015-10-191-0/+100
| | | | | | | | | | | | | | | | A REPL takes over the command line and typically treats input as source code. REPLs can also do code completion. The REPL class allows its subclasses to implement the language-specific functionality without having to know about the IOHandler-specific internals. Also added a PluginManager-based way of getting to a REPL given a language and a target. Also brought in some utility code and expression options that are useful for REPLs, such as line offsets for expressions, ANSI terminal coloring of errors, and a few IOHandler convenience functions. llvm-svn: 250753
* Fix regression caused by r249769Tamas Berghammer2015-10-091-0/+1
| | | | | | | | * Change TestSettings to test qith go instead of pascal as ToT pascal support isn't complete * Fix crash inside PluginManager llvm-svn: 249821
* Added support for enumerating the languages that actually support TypeSystemsSean Callanan2015-10-081-1/+30
| | | | | | | and expressions. Also wired that into the OptionValue infrastructure, although it isn't used for tab-completion yet. llvm-svn: 249769
* TypeSystem is now a plugin interface and removed any "ClangASTContext ↵Greg Clayton2015-09-171-0/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | &Class::GetClangASTContext()" functions. This cleans up type systems to be more pluggable. Prior to this we had issues: - Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()" - Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem - Cleaned up Module so that it no longer has dedicated type system member variables: lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module. lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module. Now we have a type system map: typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap; TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module - Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract: class CompilerType { ... //---------------------------------------------------------------------- // Return a new CompilerType that is a L value reference to this type if // this type is valid and the type system supports L value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetLValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType that is a R value reference to this type if // this type is valid and the type system supports R value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetRValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a const modifier to this type if // this type is valid and the type system supports const modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddConstModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a volatile modifier to this type if // this type is valid and the type system supports volatile modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddVolatileModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a restrict modifier to this type if // this type is valid and the type system supports restrict modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddRestrictModifier () const; //---------------------------------------------------------------------- // Create a typedef to this type using "name" as the name of the typedef // this type is valid and the type system supports typedefs, else return // an invalid type. //---------------------------------------------------------------------- CompilerType CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const; }; Other changes include: - Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);" - Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed llvm-svn: 247953
* Add an OperatingSystem plugin to support goroutinesRyan Brown2015-09-161-7/+55
| | | | | | | | | | The Go runtime schedules user level threads (goroutines) across real threads. This adds an OS plugin to create memory threads for goroutines. It supports the 1.4 and 1.5 go runtime. Differential Revision: http://reviews.llvm.org/D5871 llvm-svn: 247852
* Add plugin.jit-loader.gdb.enable-jit-breakpoint property to make JIT loader ↵Oleksiy Vyalov2015-09-161-91/+99
| | | | | | | | breakpoint optional. http://reviews.llvm.org/D12890 llvm-svn: 247821
* Add a new type of plugin: Language pluginEnrico Granata2015-08-271-0/+105
| | | | | | | | | | The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++ llvm-svn: 246212
* Convert the ScriptInterpreter system to a plugin-based one.Zachary Turner2015-07-301-0/+104
| | | | | | | | | | | | | | | | | | | | | | | Previously embedded interpreters were handled as ad-hoc source files compiled into source/Interpreter. This made it hard to disable a specific interpreter, or to add support for other interpreters and allow the developer to choose which interpreter(s) were enabled for a particular build. This patch converts script interpreters over to a plugin-based system. Script interpreters now live in source/Plugins/ScriptInterpreter, and the canonical LLDB interpreter, ScriptInterpreterPython, is moved there as well. Any new code interfacing with the Python C API must live in this location from here on out. Additionally, generic code should never need to reference or make assumptions about the presence of a specific interpreter going forward. Differential Revision: http://reviews.llvm.org/D11431 Reviewed By: Greg Clayton llvm-svn: 243681
* Make DWARF at_comp_dir symbolic links configurable via ↵Oleksiy Vyalov2015-07-291-3/+56
| | | | | | | | plugin.symbol-file.dwarf.comp-dir-symlink-paths setting. http://reviews.llvm.org/D11586 llvm-svn: 243580
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Add language command and LanguageRuntime plugin changes to allow vending of ↵Colin Riley2015-05-041-1/+14
| | | | | | | | command objects. Differential Revision: http://reviews.llvm.org/D9402 llvm-svn: 236443
OpenPOWER on IntegriCloud