summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/LanguageRuntime/ObjC
Commit message (Collapse)AuthorAgeFilesLines
...
* Rename clang_type -> compiler_type for variables.Bruce Mitchener2015-09-241-9/+9
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13102 llvm-svn: 248461
* The Visual Studio compiler does not like this C-ism when 'enum class'es are ↵Enrico Granata2015-09-231-1/+1
| | | | | | involved llvm-svn: 248429
* Make the ObjCLanguageRuntimes comply with llvm-style RTTIEnrico Granata2015-09-236-13/+45
| | | | llvm-svn: 248427
* On second thought, amend the previous patch to pass itself the ValueObject& ↵Enrico Granata2015-09-222-3/+5
| | | | | | for the static value instead of just its type llvm-svn: 248316
* Move the logic to post-process dynamic types for ValueObject purposes from ↵Enrico Granata2015-09-222-0/+34
| | | | | | | | | | | | the ValueObjects to the LanguageRuntime plugins This is meant to cover cases such as the obvious Base *base = new Derived(); where GetDynamicTypeAndAddress(base) would return the type "Derived", not "Derived *" llvm-svn: 248315
* Make LanguageRuntime::GetDynamicTypeAndAddress return a ValueTypeEnrico Granata2015-09-176-8/+16
| | | | | | | | | For C++ and ObjC, dynamic values are always (at least somewhat) pointer-like in nature, so a ValueType of scalar is actually good enough that it could originally be hardcoded as the right choice Other languages, might have broader notions of things that are dynamic (e.g. a language where a value type can be dynamic). In those cases, it might actually be the case that a dynamic value is a pointer-to the data, or even a host address if dynamic expression results entirely in host space are being talked about This patch enables the language runtime to make that decision, and makes ValueObjectDynamicValue comply with it llvm-svn: 247957
* This patch makes Clang-independent base classes for all the expression types ↵Jim Ingham2015-09-1511-218/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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
* Simplify find_first_of & find_last_of on single char.Bruce Mitchener2015-09-011-1/+1
| | | | | | | | | | | | | | | Summary: When calling find_first_of and find_last_of on a single character, we can instead just call find / rfind and make our intent more clear. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12518 llvm-svn: 246609
* Add logging to a couple of regions of codeEnrico Granata2015-09-011-2/+22
| | | | llvm-svn: 246580
* Stop objects from keeping a strong reference to the process when they should ↵Greg Clayton2015-08-312-63/+82
| | | | | | have a weak reference. llvm-svn: 246488
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-243-15/+15
| | | | | | | | | | | | | | | | | | | | 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
* ClangASTType is now CompilerType.Greg Clayton2015-08-118-27/+27
| | | | | | 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-113-13/+12
| | | | | | | | 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
* Update lldb's ExternalASTSources to match Clang r244161.Richard Smith2015-08-061-7/+0
| | | | llvm-svn: 244194
* Add UNUSED_IF_ASSERT_DISABLED and apply it.Bruce Mitchener2015-07-241-1/+1
| | | | | | | | | | | | | | | Summary: This replaces (void)x; usages where they x was subsequently involved in an assertion with this macro to make the intent more clear. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11451 llvm-svn: 243074
* Don't specify languages when setting breakpoints in C function names. We ↵Greg Clayton2015-07-222-2/+2
| | | | | | won't be able to tell from the symbol value alone what language the symbol is. llvm-svn: 242969
* Add support for specifying a language to use when parsing breakpoints.Dawn Perchik2015-07-212-0/+2
| | | | | | | | | | | | | | | | | | | | 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
* [Makefiles] Align library names with CMake buildKeno Fischer2015-07-141-3/+3
| | | | | | | | | | | | Summary: This aligns the library names used by the Makefile build to be the same as those create by the CMake build to make switching between the two easier. The only major difficulty was lldbHost which was one library in the CMake system and several in the Makefile system. Most of the other changes are trivial renames. Reviewers: labath Subscribers: emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11154 llvm-svn: 242196
* Fix build after recent clang interface changesPavel Labath2015-07-071-3/+5
| | | | llvm-svn: 241573
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-253-14/+12
| | | | | | | | | | | | | | | 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
* Fix a bug where we were trying to reconstruct ivars of ObjC types from the ↵Enrico Granata2015-06-251-1/+1
| | | | | | | | | | | | | | runtime in "expression parser mode" The expression parser mode allows UnknownAnyTy to make it all the way through, but that is bad for ivars because it means type layout fails horribly (as in, clang crashes) This patch fixes the issue by using the "variables view mode", which masks UnknownAnyTy as empty-type, and pointer-to UnknownAnyTy as void* This, in turn, allows LLDB to properly reconstruct ivars of IMP type in ObjC type - as per accompanying test case Fixes rdar://21471326 llvm-svn: 240677
* Revert "Introduce a TypeSystem interface to support adding non-clang languages."Pavel Labath2015-06-083-12/+13
| | | | | | This seems to break expression evaluation on the linux build. llvm-svn: 239366
* Introduce a TypeSystem interface to support adding non-clang languages.Pavel Labath2015-06-083-13/+12
| | | | | | | | | | | | | Reviewers: clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8712 Original Author: Ryan Brown <ribrdb@google.com> llvm-svn: 239360
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-292-4/+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 support for custom commands to set flags on themselvesEnrico Granata2015-05-271-6/+6
| | | | | | | | | This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags()) Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ... Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones llvm-svn: 238286
* Fix a few compile warningsIlia K2015-05-151-1/+1
| | | | llvm-svn: 237425
* Implement an objc tagged-pointer info command that will provide information ↵Enrico Granata2015-05-142-20/+142
| | | | | | about what LLDB thinks an ObjC tagged pointer represents llvm-svn: 237322
* I forgot to return here, so do it, and appease the compilerEnrico Granata2015-05-061-0/+1
| | | | llvm-svn: 236646
* Add a language objc class-table dump commandEnrico Granata2015-05-061-1/+104
| | | | | | This command dumps a bunch of interesting facts about all Objective-C classes known to LLDB in the inferior process llvm-svn: 236640
* Allow the gdb_objc_realized_classes symbol to beSean Callanan2015-05-061-1/+1
| | | | | | | | | any type of symbol, which is okay since we are looking only in the Objective-C module. <rdar://problem/20828139> llvm-svn: 236622
* Fix a typo in the warning.Jim Ingham2015-05-041-1/+1
| | | | | | <rdar://problem/20799707> llvm-svn: 236429
* Add new virtual method for language runtime plug-ins:Greg Clayton2015-04-162-37/+75
| | | | | | | | | virtual void LanguageRuntime::ModulesDidLoad (const ModuleList &module_list); Then reorganized how the objective C plug-in is notified so it will work for all LanguageRuntime subclasses. llvm-svn: 235118
* Don't hardcode the name of the plugin - or it will get out of date, and this ↵Enrico Granata2015-04-091-3/+3
| | | | | | | | code will be broken Thanks Greg! llvm-svn: 234539
* The dyld shared cache class table is not present in the iOS simulator, so do ↵Enrico Granata2015-04-091-0/+13
| | | | | | | | not actually warn to people when running under the simulator rdar://20403987 llvm-svn: 234537
* Fix error introduced by changing function signatures.Zachary Turner2015-03-241-11/+10
| | | | | | | | | | | | | | | | | Since ClangASTSource::layoutRecordType() was overriding a virtual function in the base, this was inadvertently causing a new method to be introduced rather than an override. To fix this all method signatures are changed back to taking DenseMaps, and the `override` keyword is added to make sure this type of error doesn't happen again. To keep the original fix intact, which is that fields and bases must be added in offset order, the ImportOffsetMap() function now copies the DenseMap into a vector and then sorts the vector on the value type (e.g. the offset) before iterating over the sorted vector and inserting the items. llvm-svn: 233099
* Fix record layout when synthesizing class types.Zachary Turner2015-03-241-6/+4
| | | | | | | | | | | | | | | | | Prior to this patch, we would try to synthesize class types by iterating over a DenseMap of FieldDecls and adding each one to a CXXRecordDecl. Since a DenseMap doesn't provide a deterministic ordering of the elements, this would not add the fields in FieldOffset order, but rather in some random order determined by the memory layout of the DenseMap. This patch fixes the issue by changing DenseMaps to vectors. The ability to lookup a value in the DenseMap was hardly being used, and where it is sufficient to do a vector lookup. Differential Revision: http://reviews.llvm.org/D8512 llvm-svn: 233090
* Remember to set m_loaded_objc_opt once you've loaded the ObjC dataJim Ingham2015-03-061-0/+2
| | | | | | | | from the shared cache so you don't update it over & over. <rdar://problem/20074768> llvm-svn: 231514
* Reduce header footprint of Target.hZachary Turner2015-03-031-0/+1
| | | | | | | | | | | | This continues the effort to reduce header footprint and improve build speed by removing clang and other unnecessary headers from Target.h. In one case, some headers were included solely for the purpose of declaring a nested class in Target, which was not needed by anybody outside the class. In this case the definition and implementation of the nested class were isolated in the .cpp file so the header could be removed. llvm-svn: 231107
* Update LLDB to read a newer format of Objective-C class information from the ↵Enrico Granata2015-02-242-26/+84
| | | | | | | | | | dyld shared cache Also, since most of the time the lack of such information is a serious problem that hinders productive debugging, emit an actual user visible warning when this occurs (once per process) Fixes rdar://19898507 llvm-svn: 230299
* Update for Clang API change in r230123 -- lookup_result was alwaysChandler Carruth2015-02-211-2/+2
| | | | | | | | const, there was never a need for lookup_const_result. Now that vestigal type is gone, so switch LLDB to lookup_result and to use the DeclContextLookupResult rather than the Const variant. llvm-svn: 230126
* Silence unused variable warnings in release buildsPavel Labath2015-02-191-0/+1
| | | | llvm-svn: 229843
* Reenable the logic to take an integer value and attempt to "po" it as an ↵Enrico Granata2015-01-141-2/+5
| | | | | | | | | | ObjC object While there is quite a bit of potential for mishaps due to tagged pointers, and after quite some internal discussion, this seems a saner behavior given how "po" stands for "print OBJECT". The argument being that we should make at least some sensible attempt to print the thing the user passed as-if it was an object Fixes rdar://19423124 llvm-svn: 226062
* If a binary was stripped we sometimes didn't show the ivars of an Objective ↵Greg Clayton2014-12-161-27/+43
| | | | | | | | | | | | | | C class correctly. Now we do as we consult the runtime data for the class so we don't have to have a symbol in the symbol table. Fixed: 1 - try the symbol table symbol for an ObjC ivar and use it if available 2 - fall back to using the runtime data since it is slower to gather via memory read 3 - Fixed our hidden ivars test case to test this to ensure we don't regress 4 - split out a test case in the hidden ivars to cover only the part that was failing so we don't have an expected failure for all of the other content in the test. <rdar://problem/18882687> llvm-svn: 224306
* Removed the assertion that we can find any namedSean Callanan2014-12-111-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Objective-C type in the runtime. This is not actually true, it's entirely possible to say @class DoesntExist; @interface DoesExist { DoesntExist *whyyyyy; } @end and this code will not only compile but also run. So this assertion will fire in situations users might encounter. I left the assertion enabled in debug mode, because we could still catch a case we're not aware of (i.e., a class that we *ought* to have found but where somehow we mis-parsed the name). <rdar://problem/19151914> llvm-svn: 224038
* Added CMake support so all the Clang modules codeSean Callanan2014-12-051-1/+1
| | | | | | | will at least be built by non-OS X builders. This should head off some build breakage at the pass. llvm-svn: 223437
* This is the meat of the code to add Clang modulesSean Callanan2014-12-057-72/+64
| | | | | | | | | | | | | | support to LLDB. It includes the following: - Changed DeclVendor to TypeVendor. - Made the ObjCLanguageRuntime provide a DeclVendor rather than a TypeVendor. - Changed the consumers of TypeVendors to use DeclVendors instead. - Provided a few convenience functions on ClangASTContext to make that easier. llvm-svn: 223433
* We should not pretend that an int is a valid ObjC pointer. If your number ↵Enrico Granata2014-12-041-5/+2
| | | | | | truly is a pointer, po (id)myNumber is a better alternative. Fixes rdar://16585032 llvm-svn: 223379
* Ignore templated aggregates in the Objective-CSean Callanan2014-11-111-0/+12
| | | | | | | | | | | | | | runtime. This eliminates potential confusion when the compiler has to deal with these weird types later on. One day I'd like to actually generate the proper templates, but this is not the day that I write the parser code to do that. <rdar://problem/18887634> llvm-svn: 221658
* Fixed two issues in the type encoding parser:Sean Callanan2014-11-111-82/+82
| | | | | | | | | | | | - A correctness issue: with assertions disabled, ReadQuotedString would misbehave; and - A performance issue: BuildType used a long chain of if()s; I changed that to two switch statements. That also makes the code much nicer to step through when debugging it. llvm-svn: 221651
OpenPOWER on IntegriCloud