summaryrefslogtreecommitdiff
path: root/lldb/source/Expression/ClangExpressionDeclMap.cpp
AgeCommit message (Collapse)Author
2015-09-25Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan
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
2015-09-22Rename clang_type_t to opaque_compiler_type_t.Bruce Mitchener
Summary: This is no longer related to Clang and is just an opaque pointer to data for a compiler type. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13039 llvm-svn: 248288
2015-09-17TypeSystem is now a plugin interface and removed any "ClangASTContext ↵Greg Clayton
&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-16Add using directives to the clang::DeclContext and fix decls for variables ↵Paul Herman
inside namespaces Summary: Supports the parsing of the "using namespace XXX" and "using XXX::XXX" directives. Added ambiguity errors when it two decls with the same name are encountered (see comments in TestCppNsImport). Fixes using directives being duplicated for anonymous namespaces. Fixes GetDeclForUID for specification DIEs. Reviewers: sivachandra, chaoren, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12897 llvm-svn: 247836
2015-09-15Search variables based on clang::DeclContext and clang::Decl treePaul Herman
Summary: SymbolFileDWARF now creates VarDecl and BlockDecl and adds them to the Decl tree. Then, in ClangExpressionDeclMap it uses the Decl tree to search for a variable. This fixes lots of variable scoping problems. Reviewers: sivachandra, chaoren, spyffe, clayborg Subscribers: tberghammer, jingham, lldb-commits Differential Revision: http://reviews.llvm.org/D12658 llvm-svn: 247746
2015-09-14ClangExpressionDeclMap should only disable the Clang parser-specific state onSean Callanan
Clang persistent variables. llvm-svn: 247615
2015-09-08ExpressionVariable now uses llvm::cast() instead of As...() for RTTI.Sean Callanan
As part of our overall switch from hand-rolling RTTI to using LLVM-compatible methods, I've done the same for ExpressionVariable. The main documentation for how to do this is in TypeSystem.h, so I've simply referred to that. llvm-svn: 247085
2015-09-08Use LLVM casting for TypeSystem so you can cast it to subclasses.Greg Clayton
This will keep our code cleaner and it removes the need for intrusive additions to TypeSystem like: class TypeSystem { virtual ClangASTContext * AsClangASTContext() = 0; } As you can now just use the llvm::dyn_cast and other casts. llvm-svn: 247041
2015-09-04This patch separates the generic portion of ClangExpressionVariable, whichSean Callanan
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
2015-09-03Lookup function using full name if one with mangled name is not found.Siva Chandra
Summary: Remove expected failure decorators from tests which now should start passing. Reviewers: clayborg, spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12613 llvm-svn: 246820
2015-08-24Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton
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
2015-08-11ClangASTType is now CompilerType.Greg Clayton
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
2015-08-11First step in getting LLDB ready to support multiple different type systems.Greg Clayton
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
2015-07-10Fixed a problem where variables in modules were not appropriately discovered bySean Callanan
the expression parser. <rdar://problem/21395220> llvm-svn: 241917
2015-06-25Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton
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
2015-06-18Fix a variety of typos.Bruce Mitchener
No functional change. llvm-svn: 239995
2015-06-08Revert "Introduce a TypeSystem interface to support adding non-clang languages."Pavel Labath
This seems to break expression evaluation on the linux build. llvm-svn: 239366
2015-06-08Introduce a TypeSystem interface to support adding non-clang languages.Pavel Labath
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
2015-05-28If we see an external function in the symbols, makeSean Callanan
it an extern "C" function instead of a C++ function so that Clang doesn't emit a mangled function reference. Also removed the hack in ClangExpressionDeclMap that works around this. llvm-svn: 238476
2015-05-15Don't allow infininte recursion when trying to resolve re-exported symbols.Greg Clayton
<rdar://problem/20821289> llvm-svn: 237477
2015-05-01Added support for locating and importing functionsSean Callanan
(including inline functions) from modules in the expression parser. We now have to retain a reference to the code generator in ClangExpressionDeclMap so that any imported function bodies can be appropriately sent to that code generator. <rdar://problem/19883002> llvm-svn: 236297
2015-04-06We have an issue where if you use a C function right now that has no ↵Greg Clayton
prototype, it isn't marked as extern "C" and the name to lookup is some C++ mangled form of the name. This used to be the case for "printf" before a function prototype was added to the builtin expression prefix file. This fix makes sure that if we get a mangled name that we don't find in the current target, that we only fall back to looking up function by basename if the function isn't contained in a namespace or class (no decl context). llvm-svn: 234178
2015-03-09Fixed a bug where the expression parser relied on having symbols for things ↵Greg Clayton
even if they were in the debug info. The issue can happen if you strip your main executable and then run an expression and it would fail to find the stripped symbol and it would then not be able to make the function call. The issue was fixed by doing our normal FindFunctions call. <rdar://problem/20072750> llvm-svn: 231667
2015-03-05When we have a symbol, like "NSLog" that we try to call in an expression, ↵Greg Clayton
make sure we prioritize the external symbols over the internal one. This is a temporary fix until a more comprehensive fix can be made for finding functions that we call in expressions. We find "NSLog" in ClangExpressionDeclMap::FindExternalVisibleDecls() in after a call to target->GetImages().FindFunctions(...). Note that there are two symbols: NSLog from CFNetwork which is not external, and NSLog from Foundation which _is_ external. We do something with the external symbol with: if (extern_symbol) { AddOneFunction (context, NULL, extern_symbol, current_id); context.m_found.function = true; } Then later we try to lookup the _Z5NSLogP8NSStringz name and we don't find it so we call ClangExpressionDeclMap::GetFunctionAddress() with "_Z5NSLogP8NSStringz" as the name and the sc_list_size is zero at the "if" statement at line 568 because we don't find the mangled name and we extract the basename "NSLog" and call: FindCodeSymbolInContext(ConstString(basename), m_parser_vars->m_sym_ctx, sc_list); sc_list_size = sc_list.GetSize(); and we get a list size of two again, and we proceed to search for the symbol again, this time ignoring the external vs non-external-ness of the symbols that we find. This fix ensures we prioritize the external symbol until we get a real fix from Sean Callanan when he gets back to make sure we don't do multiple lookups for the same symbol we already resolved. <rdar://problem/19879282> llvm-svn: 231420
2015-03-03Reduce header footprint of Target.hZachary Turner
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
2014-12-05Changes to the expression parser to actually useSean Callanan
the types that we find in Clang modules. llvm-svn: 223436
2014-11-11Made the expression parser more resilient againstSean Callanan
being asked about symbols it doesn't know about. If it's asked about a symbol by mangled name and it finds nothing, then it will try again with the demangled base name. llvm-svn: 221660
2014-10-20Don't allow the expression parser to magicallySean Callanan
look through 'self' at its ivars. It produces surprising results. <rdar://problem/18698760> llvm-svn: 220220
2014-10-16A series of bit-flag values should be bitwise-or'ed not logical-or'ed.Jason Molenda
clang unreachable code warning. llvm-svn: 219916
2014-07-06remove trailing whitespace + remove some useless commentsSylvestre Ledru
llvm-svn: 212411
2014-07-02Start converting usages of off_t to other types.Zachary Turner
off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
2014-06-13Don't dereference target if it is NULL. Greg Clayton
Caught by the clang static analyzer by Jason Molenda. llvm-svn: 210941
2014-06-13Remove unused variablesSaleem Abdulrasool
Address the 'variable set but not used' warning from GCC. In some cases a few additional calls were removed where there should be no visible side effects of the calls (i.e. should not effect any cached state). llvm-svn: 210879
2014-05-28Remove unused variable.Greg Clayton
llvm-svn: 209703
2014-05-23Fixed the Symbol code to resolve the callable addressSean Callanan
of the symbol itself rather than forcing clients to do it. This simplifies the logic for the expression parser a great deal. <rdar://problem/16935324> llvm-svn: 209494
2014-04-04sweep up -Wformat warnings from gccSaleem Abdulrasool
This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-03-20cleanup unreferenced functionsSaleem Abdulrasool
This is a mechanical cleanup of unused functions. In the case where the functions are referenced (in comment form), I've simply commented out the functions. A second pass to clean that up is warranted. The functions which are otherwise unused have been removed. Some of these were introduced in the initial commit and not in use prior to that point! NFC llvm-svn: 204310
2014-02-19Emit a warning diagnostic if a symbol was promotedSean Callanan
to a variable. This helps people figure out what happened if they tried to do something to the variable and it didn't work because we gave it the default type of void*. llvm-svn: 201737
2013-12-20Fixed the AST importer to ensure that base classesSean Callanan
of Objective-C classes are completed, and that variables of Objective-C types have their types completed when the variables are reported. This fixes a long-standing issue where ivars did not show up correctly on 32-bit OS X. <rdar://problem/12184093> llvm-svn: 197775
2013-11-04Roll back the changes I made in r193907 which created a new FrameJason Molenda
pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-02Add a new base class, Frame. It is a pure virtual function whichJason Molenda
defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
2013-10-31<rdar://problem/14496092>Greg Clayton
Fixes from code review by Jim Ingham that reinstate preferring an external vs non-external symbol when finding function addresses. llvm-svn: 193761
2013-10-30<rdar://problem/14496092>Greg Clayton
Fixed the expression parser to be able to iterate across all function name matches that it finds when it is looking for the address of a function that the IR is looking for. Also taught it to deal with reexported symbols. llvm-svn: 193716
2013-10-22Fixes to get LLDB building on Windows again.Deepak Panickal
llvm-svn: 193159
2013-10-21<rdar://problem/14496092>Greg Clayton
Fixed an issue with reexported symbols on MacOSX by adding support for symbols re-exporting symbols. There is now a new symbol type eSymbolTypeReExported which contains a new name for the re-exported symbol and the new shared library. These symbols are only used when a symbol is re-exported as a symbol under a different name. Modified the expression parser to be able to deal with finding the re-exported symbols and track down the actual symbol it refers to. llvm-svn: 193101
2013-09-05Remove a spurious comment.Jim Ingham
llvm-svn: 190027
2013-08-07clean up about 22 warnings messagesMichael Sartain
llvm-svn: 187900
2013-07-15Actually use the return value we get back whenSean Callanan
creating a persistent variable, rather than making a (potentially expensive) lookup by name. <rdar://problem/14337653> llvm-svn: 186337
2013-07-11Huge change to clean up types.Greg Clayton
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-10Cleanup on the unified section list changes. Main changes are:Greg Clayton
- ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags - Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections. Other cleanups: - Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly - Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently - Modified the Symtab class to store a file address lookup table for more efficient lookups - Removed Section::Finalize() and SectionList::Finalize() as they did nothing - Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs - Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement) llvm-svn: 185990