summaryrefslogtreecommitdiffstats
path: root/lldb/source/API
Commit message (Collapse)AuthorAgeFilesLines
* Summary provider for char.Dawn Perchik2015-10-231-0/+19
| | | | | | | | | | | | | | | | | | | This patch enables type summary for 'char' type. Given: char c = 'h'; Before this patch, c evaluates as: (char) $0 = 'h' After this patch, we get: (char) $0 = 104 'h' This change allows the formatting of character types in MI to be removed and replaced with that in lldb, and can be useful when evaluating non-printable characters. Patch from evgeny.leviant@gmail.com Reviewed by: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13657 llvm-svn: 251080
* [SBValue] Add a method GetNumChildren(uint32_t max)Siva Chandra2015-10-212-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Rationalization of includes in the data formatters codeEnrico Granata2015-10-201-0/+1
| | | | llvm-svn: 250798
* Added support for the "--repl" argument to LLDB. Sean Callanan2015-10-201-0/+11
| | | | | | | | | This makes LLDB launch and create a REPL, specifying no target so that the REPL can create one for itself. Also added the "--repl-language" option, which specifies the language to use. Plumbed the relevant arguments and errors through the REPL creation mechanism. llvm-svn: 250773
* Move TypeSummaryImpl over to LLVM-style RTTI for subclassingEnrico Granata2015-10-161-54/+40
| | | | llvm-svn: 250567
* Fix linkage of `init_lldb` SWIG method in Python 3.Zachary Turner2015-10-161-1/+11
| | | | llvm-svn: 250531
* Fix build with python disabled after r249597Keno Fischer2015-10-162-8/+0
| | | | | | | | | | | | | | | Summary: r249597 introduced a usage of GetTypeSummary in lldb-mi. That function used to only be available when python is enabled. However, there is no reason for that anymore since that is now dealt with at a different abstraction layer. Reviewers: ki.stfu, evgeny777, clayborg, granata.enrico Subscribers: elehcim, brucem, lldb-commits Differential Revision: http://reviews.llvm.org/D13577 llvm-svn: 250494
* cmake: provide flag that enables 'log enable --stack' to provide useful ↵Todd Fiala2015-10-141-1/+15
| | | | | | | | | | | | | | | | | | | | file/function info on POSIX systems Adding the following flag to a cmake line: -DLLDB_EXPORT_ALL_SYMBOLS=TRUE will cause all symbols to be exported from liblldb. This enables the llvm backtrace mechanism to see and report backtrace symbols properly when using (lldb) log enable --stack ... Prior to this change, only the SB API symbols would show up on Linux and other systems that use a public-symbols-based backtrace lookup mechanism. log enable --stack ... is a very handy, quick way to understand the flow of how some log lines are getting hit within lldb without having to hook up a top-level debugger over your current debug session. llvm-svn: 250299
* Fix handling of LLDB_VERS_GENERATED_FILE.Bruce Mitchener2015-10-091-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is Darwin only. The symbol defined by ${LLDB_VERS_GENERATED_FILE} is used by source/lldb.cpp, so anything that uses lldb.cpp (which is in lldbBase) should also have the generated symbol. This means that the entire process can be centralized within source/CMakeLists.txt where lldbBase is constructed. Additionally, the custom command should have dependencies on the project file as well as the generation script so that if either changes, the version file is correctly re-generated and everything is re-linked appropriately. * cmake/LLDBDependencies.cmake: Remove everything related to the generated version file from here. * source/CMakeLists.txt: On Darwin, add the generated version file to the sources that make up lldbBase. Also, create a custom target and make lldbBase depend on it to re-generate the generated file as needed. * source/API/CMakeLists.txt: Don't need to build the generated version file here or use it to control linking against swig_wrapper. * tools/lldb-server/CMakeLists.txt: Likewise. Reviewers: dawn, sas, clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13552 llvm-svn: 249806
* [lldb-mi] Fix evaluation of strings containing characters from non-ascii rangeDawn Perchik2015-10-071-2/+10
| | | | | | | | | | | | | | | | If a string contained characters outside the ASCII range, lldb-mi would print them as hexadecimal codes. This patch fixes this behaviour by converting to UTF-8 instead, by having lldb-mi use registered type summary providers, when they are available. This patch also fixes incorrect evaluation of some composite types, like std::string, by having them use a type registered type summary provider. Based on patch from evgeny.leviant@gmail.com Reviewed by: ki.stfu, granata.enrico, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13058 llvm-svn: 249597
* Create GoLanguageRuntime.Ryan Brown2015-10-061-0/+2
| | | | | | GoLanguageRuntime supports finding the runtime type for Go interfaces. llvm-svn: 249456
* SBTarget::Attach(SBAttachInfo &) was changed to not be asynchronous back in ↵Greg Clayton2015-10-051-0/+16
| | | | | | | | | | February and this affected Xcode's abililty to cancel an attach to process by name. Added the ability to specify if an attach by name should be synchronous or not in SBAttachInfo and ProcessAttachInfo. <rdar://problem/22821480> llvm-svn: 249361
* Now persistent expression data no longer lives with the Target, but rather withSean Callanan2015-09-301-1/+1
| | | | | | | | | | the corresponding TypeSystem. This makes sense because what kind of data there is -- and how it can be looked up -- depends on the language. Functionality that is common to all type systems is factored out into PersistentExpressionState. llvm-svn: 248934
* Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan2015-09-251-1/+1
| | | | | | | | | There are still a bunch of dependencies on the plug-in, but this helps to identify them. There are also a few more bits we need to move (and abstract, for example the ClangPersistentVariables). llvm-svn: 248612
* Rename clang_type -> compiler_type for variables.Bruce Mitchener2015-09-241-3/+3
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13102 llvm-svn: 248461
* Fix typos.Bruce Mitchener2015-09-221-1/+1
| | | | | | | | | | | | Summary: Another round of minor typo fixes. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13026 llvm-svn: 248243
* Reduce inclusion of clang headers.Bruce Mitchener2015-09-182-3/+0
| | | | | | | | | | | | | | Summary: With the recent changes to separate clang from the core structures of LLDB, many inclusions of clang headers can be removed. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12954 llvm-svn: 248004
* TypeSystem is now a plugin interface and removed any "ClangASTContext ↵Greg Clayton2015-09-173-6/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | &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
* This patch makes Clang-independent base classes for all the expression types ↵Jim Ingham2015-09-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that lldb currently vends. Before we had: ClangFunction ClangUtilityFunction ClangUserExpression and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression base class, and three pure virtual implementations for the Expression kinds: FunctionCaller UtilityFunction UserExpression You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. The Target will then consult all the registered TypeSystem plugins, and if the type system that matches the language can make an expression of that kind, it will do so and return it. Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs. The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions. Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary. llvm-svn: 247720
* Fix log message warning in SBThread.Bruce Mitchener2015-09-091-1/+1
| | | | | | | | | | | | | | | Summary: The format string was not set up correctly as it was missing the %. This resulted in a warning (correctly) that the data arguments were not all used. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12714 llvm-svn: 247111
* SBThread::StepOutOfFrame should check that the SBStackFrame it gets passedJim Ingham2015-09-081-1/+15
| | | | | | is valid, and that its thread is the same as this SBThread. llvm-svn: 247046
* Use eAddressClassCode for address lookup for opcodes for stack framesTamas Berghammer2015-09-071-1/+1
| | | | | | | | | | | | | | | It is required because of the following edge case on arm: bx <addr> Non-tail call in a no return function [data-pool] Marked with $d mapping symbol The return address of the function call will point to the data pool but we have to treat it as code so the StackFrame can calculate the symbols correctly. Differential revision: http://reviews.llvm.org/D12556 llvm-svn: 246958
* This patch separates the generic portion of ClangExpressionVariable, whichSean Callanan2015-09-041-1/+1
| | | | | | | | | stores information about a variable that different parts of LLDB use, from the compiler-specific portion that only the expression parser cares about. http://reviews.llvm.org/D12602 llvm-svn: 246871
* Only export public symbols with the cmake build.Bruce Mitchener2015-09-043-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This also moves the xcode support files to be near or the same as the ones used for cmake. The source/API/liblldb.xcodes.exports differs from the source/API/liblldb.exports in that one contains the actual symbol names (_ prefixed) while the other contains the symbol names as they are in the code. The liblldb.exports file is preprocessed by the cmake scripts into the correct per-platform file needed (like a linker script on Linux). This is not enabled on Windows as Windows doesn't use the same name mangling and so it won't be valid there. Also, this is handled already in a different way on Windows (via dll exports). Reviewers: emaste, clayborg, labath, chaoren Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12599 llvm-svn: 246822
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-031-2/+0
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Move things from the LanguageRuntime that obviously belong in the new ↵Jim Ingham2015-09-022-4/+5
| | | | | | Language plugin instead. llvm-svn: 246611
* Add support for language plugins to provide data formatters (second attempt)Enrico Granata2015-09-011-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
* Revert "Add support for language plugins to provide data formatters"Pavel Labath2015-09-011-11/+0
| | | | | | This reverts r246515 (and related cmake fixes) as it breaks all libcxx tests. llvm-svn: 246536
* Add support for language plugins to provide data formattersEnrico Granata2015-09-011-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
* Switch data formatters over to using std::function for their callbacks ↵Enrico Granata2015-08-271-1/+1
| | | | | | instead of raw function pointers. NFC llvm-svn: 246130
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-242-39/+20
| | | | | | | | | | | | | | | | | | | | lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
* Reorg code to allow Windows Process Plugins to share some common code.Adrian McCarthy2015-08-241-2/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D12252 llvm-svn: 245850
* Also initialize ScriptInterpreterNone if Python is disabledKeno Fischer2015-08-231-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
* Convert GetNumTemplateArguments() and GetTemplateArgument() to be instance ↵Enrico Granata2015-08-131-3/+3
| | | | | | functions on the CompilerType and the TypeSystem llvm-svn: 244846
* ClangASTType is now CompilerType.Greg Clayton2015-08-115-49/+49
| | | | | | This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
* First step in getting LLDB ready to support multiple different type systems.Greg Clayton2015-08-111-12/+17
| | | | | | | | This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system. All tests pass on MacOSX and passed on linux the last time this was submitted. llvm-svn: 244679
* Create a Windows mini-dump target Differential Revision: ↵Adrian McCarthy2015-08-031-0/+7
| | | | | | http://reviews.llvm.org/D11611 llvm-svn: 243914
* Convert the ScriptInterpreter system to a plugin-based one.Zachary Turner2015-07-303-11/+29
| | | | | | | | | | | | | | | | | | | | | | | 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
* First part of an attempt to indicate to the user when they are Jason Molenda2015-07-291-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | debugging optimized code. Adds new methods on Function/SBFunction to query whether a given function is optimized. Adds a new function.is-optimized format entity and changes the default frame-format to append "[opt]" if the function was built with optimization. The only indication that a binary was built with optimization that we have right now is the presence of the DW_AT_APPLE_optimized attribute (DW_FORM_flag value 1) in the DW_TAG_compile_unit. The absence of this flag may mean that the compile_unit was not compiled with optimization, or it may mean that the producer does not generate this attribute. Currently this only works for dSYM debugging. When we create the CompileUnit with dwarf-in-.o-file debugging we don't have the attribute value yet so it's not set. I need to find the flag value when we do start to read the .o file DWARF and set the CompileUnit's status at that point - but haven't done it yet. I'm also going to add a mechanism for issuing warnings to users such that they're only issued once in a debug session and there is away for users to suppress these warnings altogether via .lldbinit file settings. But I want to get this changeset committed now that it's at a useful state. <rdar://problem/19281172> llvm-svn: 243508
* Fix warnings detected by -Wpessimizing-movePavel Labath2015-07-281-1/+1
| | | | | | | | patch by Eugene Zelenko Differential Revision: http://reviews.llvm.org/D11429 llvm-svn: 243399
* Deprecate `SBValue::TypeIsPointerType`.Chaoren Lin2015-07-271-13/+2
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11540 llvm-svn: 243333
* Fix warnings found by -Wextra-semiPavel Labath2015-07-221-3/+1
| | | | | | patch by Eugene Zelenko. llvm-svn: 242875
* Add support for specifying a language to use when parsing breakpoints.Dawn Perchik2015-07-211-2/+4
| | | | | | | | | | | | | | | | | | | | Target and breakpoints options were added: breakpoint set --language lang --name func settings set target.language pascal These specify the Language to use when interpreting the breakpoint's expression (note: currently only implemented for breakpoints on identifiers). If the breakpoint language is not set, the target.language setting is used. This support is required by Pascal, for example, to set breakpoint at 'ns.foo' for function 'foo' in namespace 'ns'. Tests on the language were also added to Module::PrepareForFunctionNameLookup for efficiency. Reviewed by: clayborg Subscribers: jingham, lldb-commits Differential Revision: http://reviews.llvm.org/D11119 llvm-svn: 242844
* Refactor Unix signals.Chaoren Lin2015-07-144-62/+64
| | | | | | | | | | | | | | | | | | Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
* Make many mangled functions that might demangle a name be allowed to specify ↵Greg Clayton2015-07-084-7/+15
| | | | | | a language to use in order to soon support Pascal and Java demangling. Dawn Perchik will take care of making this so. llvm-svn: 241751
* Move WindowsDYLD to the Plugins/DynamicLoader directory.Stephane Sezer2015-07-081-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
* Add a version of SBTarget::EvaluateExpression that doesn't requireJim Ingham2015-07-071-0/+13
| | | | | | | | an options (and makes an appropriate defaulted option for you.) <rdar://problem/20639202> llvm-svn: 241632
* Add a GetDisplayName() API to SBFrame, SBFunction and SBSymbolEnrico Granata2015-07-063-0/+90
| | | | | | | | | | This API is currently a no-op (in the sense that it has the same behavior as the already existing GetName()), but is meant long-term to provide a best-for-visualization version of the name of a function It is still not hooked up to the command line 'bt' command, nor to the 'gui' mode, but I do have ideas on how to make that work going forward rdar://21203242 llvm-svn: 241482
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-252-6/+7
| | | | | | | | | | | | | | | A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
* Submitting patch from Abhishek for:Greg Clayton2015-06-251-0/+3
| | | | | | http://reviews.llvm.org/D10309 llvm-svn: 240663
OpenPOWER on IntegriCloud