aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/API/SystemInitializerFull.cpp
AgeCommit message (Collapse)AuthorFilesLines
2018-05-22Enable ProcessMachCore plugin on non-apple platformsPavel Labath1-3/+3
Summary: The plugin already builds fine on other platforms (linux, at least). All that was necessary was to revitalize the hack in PlatformDarwinKernel (not a very pretty hack, but it gets us going at least). I haven't done a thorough investigation of the state of the plugin on other platforms, but at least the two core file tests we have seem to pass, so I enable them. Reviewers: JDevlieghere, jasonmolenda Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D47133 llvm-svn: 332997
2018-04-30Reflow paragraphs in comments.Adrian Prantl1-13/+11
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
2018-03-12Re-add change for https://reviews.llvm.org/D42582 with added directories.Jim Ingham1-0/+2
llvm-svn: 327331
2018-03-12Revert "Improve prologue handling to support functions with multiple entry ↵Vedant Kumar1-2/+0
points." This reverts commit r327318. It breaks the Xcode and CMake Darwin builders: clang: error: no such file or directory: '.../source/Plugins/Architecture/PPC64/ArchitecturePPC64.cpp' clang: error: no input files More details are in https://reviews.llvm.org/D42582. llvm-svn: 327327
2018-03-12Improve prologue handling to support functions with multiple entry points.Jim Ingham1-0/+2
https://reviews.llvm.org/D42582 Patch from Leandro Lupori. llvm-svn: 327318
2018-02-27[LLDB] Initial version of PPC64 InstEmulationPavel Labath1-0/+3
Summary: Supports common prologue/epilogue instructions. Reviewers: clayborg, labath Reviewed By: clayborg, labath Subscribers: davide, anajuliapc, alexandreyy, lbianc, nemanjai, mgorny, kbarton Differential Revision: https://reviews.llvm.org/D43345 Author: Leandro Lupori <leandro.lupori@gmail.com> llvm-svn: 326224
2017-10-25Move StopInfoOverride callback to the new architecture pluginPavel Labath1-1/+5
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
2017-06-29Move Timer and TraceOptions from Core to UtilityPavel Labath1-1/+1
Summary: The classes have no dependencies, and they are used both by lldb and lldb-server, so it makes sense for them to live in the lowest layers. Reviewers: zturner, jingham Subscribers: emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D34746 llvm-svn: 306682
2017-06-26Shorten sanitizer plugin namesPavel Labath1-3/+3
Summary: The new UndefinedBehaviorSanitizer plugin was breaking file path length limits, because it's (fairly long name) appears multiple times in the path. Cmake ends up putting the object file at path tools/lldb/source/Plugins/InstrumentationRuntime/UndefinedBehaviorSanitizer/CMakeFiles/lldbPluginInstrumentationRuntimeUndefinedBehaviorSanitizer.dir/UndefinedBehaviorSanitizerRuntime.cpp.obj which is 191 characters long and very dangerously close to the 260 character path limit on windows systems (also, just the include line for that file was breaking the 80 character line limit). This renames the sanitizer plugins to use shorter names (asan, ubsan, tsan). I think this will still be quite understandable to everyone as those are the names everyone uses to refer to them anyway. Reviewers: zturner, kubamracek, jingham Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D34553 llvm-svn: 306278
2017-06-16Upstreaming the UndefinedBehaviorSanitizerRuntime and ↵Kuba Mracek1-0/+6
MainThreadCheckerRuntime plugins. llvm-svn: 305589
2017-05-15Remove an expensive lock from TimerPavel Labath1-1/+2
The Timer destructor would grab a global mutex in order to update execution time. Add a class to define a category once, statically; the class adds itself to an atomic singly linked list, and thus subsequent updates only need to use an atomic rather than grab a lock and perform a hashtable lookup. Differential Revision: https://reviews.llvm.org/D32823 Patch by Scott Smith <scott.smith@purestorage.com>. llvm-svn: 303058
2017-03-26[LLDB] OpenBSD supportKamil Rytarowski1-0/+3
Summary: Add basic OpenBSD support. This is enough to be able to analyze core dumps for OpenBSD/amd64, OpenBSD/arm, OpenBSD/arm64 and OpenBSD/i386. Note that part of the changes to source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp fix a bug that probably affects other platforms as well. The GetProgramHeaderByIndex() interface use 1-based indices, but in some case when looping over the headers the, the loop starts at 0 and misses the last header. This caused problems on OpenBSD since OpenBSD core dumps have the PT_NOTE segment as the last program header. Reviewers: joerg, labath, krytarowski Reviewed By: krytarowski Subscribers: aemerson, emaste, rengolin, srhines, krytarowski, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D31131 llvm-svn: 298810
2016-12-15Fix build for mingw.Hafiz Abid Qadeer1-2/+2
Summary: I was building lldb using cross mingw-w64 toolchain on Linux and observed some issues. This is first patch in the series to fix that build. It mostly corrects the case of include files and adjusts some #ifdefs from _MSC_VER to _WIN32 and vice versa. I built lldb on windows with VS after applying this patch to make sure it does not break the build there. Reviewers: zturner, labath, abidh Subscribers: ki.stfu, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D27759 llvm-svn: 289821
2016-11-23Refactor LLDB's Windows process plugin (NFC)Adrian McCarthy1-2/+2
The Windows process plugin was broken up into multiple pieces a while back in order to share code between debugging live processes and minidumps (postmortem) debugging. The minidump portion was replaced by a cross-platform solution. This left the plugin split into a formerly "common" base classes and the derived classes for live debugging. This extra layer made the code harder to understand and work with. This patch simplifies these class hierarchies by rolling the live debugging concrete classes up to the base classes. Last week I posted my intent to make this change to lldb-dev, and I didn't hear any objections. This involved moving code and changing references to classes like ProcessWindowsLive to ProcessWindows. It still builds for both 32- and 64-bit, and the tests still pass on 32-bit. (Tests on 64-bit weren't passing before this refactor for unrelated reasons.) llvm-svn: 287770
2016-11-09Disable windows-only minidump pluginPavel Labath1-7/+0
Summary: This commit disables the windows-only minidump plugin and enables the new cross-platform plugin for windows minidump files. Test decorators are adjusted to reflect that: windows minidump tests can now run on all platforms. The exception is the tests that create minidump files, as that functionality is not available yet. I've checked that this works on windows and linux. Reviewers: amccarth, zturner Subscribers: dvlahovski, lldb-commits Differential Revision: https://reviews.llvm.org/D26393 llvm-svn: 286352
2016-10-31Minidump plugin: Adding ProcessMinidump, ThreadMinidump and register the ↵Dimitar Vlahovski1-0/+3
plugin in SystemInitializerFull Summary: This plugin resembles the already existing Windows-only Minidump plugin. The WinMinidumpPlugin uses the Windows API for parsing Minidumps while this plugin is cross-platform because it includes a Minidump parser (which is already commited) It is able to produce a backtrace, to read the general puprose regiters, inspect local variables, show image list, do memory reads, etc. For now the only arches that this supports are x86_32 and x86_64. This is because I have only written register contexts for those. Others will come in next CLs. I copied the WinMinidump tests and adapted them a little bit for them to work with the new plugin (and they pass) I will add more tests, aiming for better code coverage. There is still functionality to be added, see TODOs in code. Reviewers: labath, zturner Subscribers: beanz, mgorny, modocache, lldb-commits, amccarth Differential Revision: https://reviews.llvm.org/D25905 llvm-svn: 285587
2016-10-05Removing the new Minidump pluginDimitar Vlahovski1-4/+0
Tests are failing and build is failing on windows and darwin. Will fix and commit it later ------------------------------------------------------------- Revert "xfailing minidump tests again ... :(" This reverts commit 97eade002c9e43c1e0d11475a4888083a8965044. Revert "Fixing new Minidump plugin tests" This reverts commit 0dd93b3ab39c8288696001dd50b9a093b813b09c. Revert "Add the new minidump files to the Xcode project." This reverts commit 2f638a1d046b8a88e61e212220edc40aecd2ce44. Revert "xfailing tests for Minidump plugin" This reverts commit 99311c0b22338a83e6a00c4fbddfd3577914c003. Revert "Adding a new Minidump post-mortem debugging plugin" This reverts commit b09a7e4dae231663095a84dac4be3da00b03a021. llvm-svn: 283352
2016-10-04Adding a new Minidump post-mortem debugging pluginDimitar Vlahovski1-0/+4
Summary: This plugin resembles the already existing Windows-only Minidump plugin. The WinMinidumpPlugin uses the Windows API for parsing Minidumps while this plugin is cross-platform because it includes a Minidump parser (which is already commited) It is able to produce a backtrace, to read the general puprose regiters, inspect local variables, show image list, do memory reads, etc. For now the only arch that this supports is x86 64 bit This is because I have only written a register context for that arch. Others will come in next CLs. I copied the WinMinidump tests and adapted them a little bit for them to work with the new plugin (and they pass) I will add more tests, aiming for better code coverage. There is still functionality to be added, see TODOs in code. Reviewers: labath, zturner Subscribers: beanz, mgorny, amccarth, lldb-commits, modocache Differential Revision: https://reviews.llvm.org/D25196 llvm-svn: 283259
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone1-335/+291
*** 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
2016-08-19Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala1-0/+8
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
2016-08-19Revert "Add StructuredData plugin type; showcase with new DarwinLog feature"Todd Fiala1-8/+0
This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8. llvm-svn: 279200
2016-08-19Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala1-0/+8
See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279198
2016-08-09Delete Host/windows/win32.hZachary Turner1-1/+1
It's always hard to remember when to include this file, and when you do include it it's hard to remember what preprocessor check it needs to be behind, and then you further have to remember whether it's windows.h or win32.h which you need to include. This patch changes the name to PosixApi.h, which is more appropriately named, and makes it independent of any preprocessor setting. There's still the issue of people not knowing when to include this, because there's not a well-defined set of things it exposes other than "whatever is missing on Windows", but at least this should make it less painful to fix when problems arise. This patch depends on LLVM revision r278170. llvm-svn: 278177
2016-08-02Support for OCaml native debuggingTamas Berghammer1-0/+6
This introduces basic support for debugging OCaml binaries. Use of the native compiler with DWARF emission support (see https://github.com/ocaml/ocaml/pull/574) is required. Available variables are considered as 64 bits unsigned integers, their interpretation will be left to a OCaml-made debugging layer. Differential revision: https://reviews.llvm.org/D22132 llvm-svn: 277443
2016-07-21Add a new DynamicLoader plugin that uses SPI that are in developmentJason Molenda1-0/+3
for the fall (northern hemisphere) 2016 Darwin platforms to learn about loaded images, instead of reading dyld internal data structures. These new SPI don't exist on older releases, and new packets are needed from debugserver to use them (those changes are already committed). I had to change the minimum deployment target for debugserver in the xcode project file to macOS 10.10 so that debugserver will use the [[NSProcessInfo processInfo] operatingSystemVersion] call in MachProcess::GetOSVersionNumbers to get the operarting system version # -- this API is only available in macOS 10.10 and newer ("OS X Yosemite", released Oct 2014). If we have many people building llvm.org lldb on older systems still, we can back off on this for the llvm.org sources. There should be no change in behavior with this commit, either to older darwin systems or newer darwin systems. For now the new DynamicLoader plugin is never activated - I'm forcing the old plugin to be used in DynamicLoaderDarwin::UseDYLDSPI. I'll remove that unconditional use of the old plugin soon, so the newer plugin is used on the newest Darwin platforms. <rdar://problem/25251243> llvm-svn: 276254
2016-06-29Remove platform plugins from lldb-serverPavel Labath1-6/+42
Summary: This removes the last usage of Platform plugins in lldb-server -- it was used for launching child processes, where it can be trivially replaced by Host::LaunchProces (as lldb-server is always running on the host). Removing platform plugins enables us to remove a lot of other unused code, which was pulled in as a transitive dependency, and it reduces lldb-server size by 4%--9% (depending on build type and architecture). Reviewers: clayborg Subscribers: tberghammer, danalbert, srhines, lldb-commits Differential Revision: http://reviews.llvm.org/D20440 llvm-svn: 274125
2016-04-14Support Linux on SystemZ as platformUlrich Weigand1-0/+3
This patch adds support for Linux on SystemZ: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). There is no instruction emulation, since our ABI requires that all code provide correct DWARF CFI at all PC locations in .eh_frame to support unwinding (i.e. -fasynchronous-unwind-tables is on by default). The implementation follows existing platforms in a mostly straightforward manner. A couple of things that are different: - We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets. - SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changed those to simply use plain write watchpoints. ] Differential Revision: http://reviews.llvm.org/D18978 llvm-svn: 266308
2016-03-29Move DynamicLoader plugins to SystemInitializerFullPavel Labath1-0/+12
Summary: These are not needed by lldb-server. Removing them shrinks the server by about 0.5%. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18206 llvm-svn: 264735
2016-03-23Add ThreadSanitizer debugging support.Kuba Brecka1-0/+3
This patch adds ThreadSanitizer support into LLDB: - Adding a new InstrumentationRuntime plugin, ThreadSanitizerRuntime, in the same way ASan is implemented. - A breakpoint stops in `__tsan_on_report`, then we extract all sorts of information by evaluating an expression. We then populate this into StopReasonExtendedInfo. - SBThread gets a new API, SBThread::GetStopReasonExtendedBacktraces(), which returns TSan’s backtraces in the form of regular SBThreads. Non-TSan stop reasons return an empty collection. - Added some test cases. Reviewed by Greg Clayton. llvm-svn: 264162
2016-03-16Move OperatingSystem plugins to SystemInitializerFullPavel Labath1-0/+12
Summary: These are not needed in lldb-server. Removing them shrinks the server size by about 1.5%. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18188 llvm-svn: 263625
2016-03-02Add support for reading line tables from PDB files.Zachary Turner1-7/+10
PDB is Microsoft's debug information format, and although we cannot yet generate it, we still must be able to consume it. Reason for this is that debug information for system libraries (e.g. kernel32, C Runtime Library, etc) only have debug info in PDB format, so in order to be able to support debugging of system code, we must support it. Currently this code should compile on every platform, but on non-Windows platforms the PDB plugin will return 0 capabilities, meaning that for now PDB is only supported on Windows. This may change in the future, but the API is designed in such a way that this will require few (if any) changes on the LLDB side. In the future we can just flip a switch and everything will work. This patch only adds support for line tables. It does not return information about functions, types, global variables, or anything else. This functionality will be added in a followup patch. Differential Revision: http://reviews.llvm.org/D17363 Reviewed by: Greg Clayton llvm-svn: 262528
2016-02-26Add a set of new plugins to handle Java debuggingTamas Berghammer1-0/+9
The purpose of these plugins is to make LLDB capable of debugging java code JIT-ed by the android runtime. Differential revision: http://reviews.llvm.org/D17616 llvm-svn: 262015
2016-01-04Strip trailing whitespaceEd Maste1-3/+3
(There are changes in the copies of these four files in the FreeBSD base system, and I've changed these ones to reduce gratuitous diffs in future imports.) llvm-svn: 256723
2015-12-10Add Hexagon ABI to System InitializationTed Woodward1-0/+3
Summary: When the Hexagon ABI was added, it was inadvertently left out of initialization/termination. This patch adds it. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15347 llvm-svn: 255268
2015-11-06Add PlatformRemoteAppleWatch (apple watch), PlatformRemoteAppleTV (apple tv),Jason Molenda1-0/+12
PlatformAppleWatchSimulator (apple watch simulator), PlatformAppleTVSimulator (apple tv simulator). llvm-svn: 252251
2015-11-05Add go data formatters.Ryan Brown1-0/+3
Differential Revision: http://reviews.llvm.org/D13878 llvm-svn: 252109
2015-10-28Refactor Windows process plugin to allow code sharing between live and mini ↵Adrian McCarthy1-2/+2
dump debugging. llvm-svn: 251540
2015-10-21[SBValue] Add a method GetNumChildren(uint32_t max)Siva Chandra1-1/+1
Summary: Along with this, support for an optional argument to the "num_children" method of a Python synthetic child provider has also been added. These have been added with the following use case in mind: Synthetic child providers currently have a method "has_children" and "num_children". While the former is good enough to know if there are children, it does not give any insight into how many children there are. Though the latter serves this purpose, calculating the number for children of a data structure could be an O(N) operation if the data structure has N children. The new method added in this change provide a middle ground. One can call GetNumChildren(K) to know if a child exists at an index K which can be as large as the callers tolerance can be. If the caller wants to know about children beyond K, it can make an other call with 2K. If the synthetic child provider maintains state about it counting till K previosly, then the next call is only an O(K) operation. Infact, all calls made progressively with steps of K will be O(K) operations. Reviewers: vharron, clayborg, granata.enrico Subscribers: labath, lldb-commits Differential Revision: http://reviews.llvm.org/D13778 llvm-svn: 250930
2015-10-16Fix linkage of `init_lldb` SWIG method in Python 3.Zachary Turner1-1/+11
llvm-svn: 250531
2015-10-06Create GoLanguageRuntime.Ryan Brown1-0/+2
GoLanguageRuntime supports finding the runtime type for Go interfaces. llvm-svn: 249456
2015-09-17TypeSystem is now a plugin interface and removed any "ClangASTContext ↵Greg Clayton1-0/+9
&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
2015-09-01Add support for language plugins to provide data formatters (second attempt)Enrico Granata1-0/+11
Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
2015-09-01Revert "Add support for language plugins to provide data formatters"Pavel Labath1-11/+0
This reverts r246515 (and related cmake fixes) as it breaks all libcxx tests. llvm-svn: 246536
2015-09-01Add support for language plugins to provide data formattersEnrico Granata1-0/+11
Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246515
2015-08-24Reorg code to allow Windows Process Plugins to share some common code.Adrian McCarthy1-2/+2
Differential Revision: http://reviews.llvm.org/D12252 llvm-svn: 245850
2015-08-23Also initialize ScriptInterpreterNone if Python is disabledKeno Fischer1-1/+1
Summary: We get an assertion otherwise because the None Interpreter cannot be found Reviewers: zturner Subscribers: zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D11898 llvm-svn: 245808
2015-08-03Create a Windows mini-dump target Differential Revision: ↵Adrian McCarthy1-0/+7
http://reviews.llvm.org/D11611 llvm-svn: 243914
2015-07-30Convert the ScriptInterpreter system to a plugin-based one.Zachary Turner1-10/+21
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
2015-07-08Move WindowsDYLD to the Plugins/DynamicLoader directory.Stephane Sezer1-5/+0
Summary: This commit moves the Windows DyanamicLoader to the common DynamicLoader directory. This is required to remote debug Windows targets. This commit also initializes the Windows DYLD plugin in SystemInitializerCommon (similarly to both POSIX and MacOSX DYLD plugins) so that we can automatically instantiate this class when connected to a windows process. Test Plan: Build. Reviewers: zturner Subscribers: lldb-commits, abdulras Differential Revision: http://reviews.llvm.org/D10882 llvm-svn: 241697
2015-06-25Submitting patch from Abhishek for:Greg Clayton1-0/+3
http://reviews.llvm.org/D10309 llvm-svn: 240663