summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression/ClangExpressionDeclMap.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Lookup function using full name if one with mangled name is not found.Siva Chandra2015-09-031-5/+32
| | | | | | | | | | | | | | 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
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-39/+31
| | | | | | | | | | | | | | | | | | | | 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-111-12/+12
| | | | | | 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-29/+31
| | | | | | | | 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
* Fixed a problem where variables in modules were not appropriately discovered bySean Callanan2015-07-101-0/+25
| | | | | | | | the expression parser. <rdar://problem/21395220> llvm-svn: 241917
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-251-64/+61
| | | | | | | | | | | | | | | 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 variety of typos.Bruce Mitchener2015-06-181-2/+2
| | | | | | No functional change. llvm-svn: 239995
* Revert "Introduce a TypeSystem interface to support adding non-clang languages."Pavel Labath2015-06-081-31/+29
| | | | | | 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-081-29/+31
| | | | | | | | | | | | | 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
* If we see an external function in the symbols, makeSean Callanan2015-05-281-23/+0
| | | | | | | | | | 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
* Don't allow infininte recursion when trying to resolve re-exported symbols.Greg Clayton2015-05-151-0/+5
| | | | | | <rdar://problem/20821289> llvm-svn: 237477
* Added support for locating and importing functionsSean Callanan2015-05-011-0/+64
| | | | | | | | | | | | (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
* We have an issue where if you use a C function right now that has no ↵Greg Clayton2015-04-061-6/+10
| | | | | | | | 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
* Fixed a bug where the expression parser relied on having symbols for things ↵Greg Clayton2015-03-091-16/+39
| | | | | | | | | | 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
* When we have a symbol, like "NSLog" that we try to call in an expression, ↵Greg Clayton2015-03-051-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* Changes to the expression parser to actually useSean Callanan2014-12-051-0/+23
| | | | | | the types that we find in Clang modules. llvm-svn: 223436
* Made the expression parser more resilient againstSean Callanan2014-11-111-0/+21
| | | | | | | | | 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
* Don't allow the expression parser to magicallySean Callanan2014-10-201-1/+0
| | | | | | | | | look through 'self' at its ivars. It produces surprising results. <rdar://problem/18698760> llvm-svn: 220220
* A series of bit-flag values should be bitwise-or'ed not logical-or'ed.Jason Molenda2014-10-161-4/+4
| | | | | | clang unreachable code warning. llvm-svn: 219916
* remove trailing whitespace + remove some useless commentsSylvestre Ledru2014-07-061-336/+331
| | | | llvm-svn: 212411
* Start converting usages of off_t to other types.Zachary Turner2014-07-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | 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
* Don't dereference target if it is NULL. Greg Clayton2014-06-131-1/+1
| | | | | | Caught by the clang static analyzer by Jason Molenda. llvm-svn: 210941
* Remove unused variablesSaleem Abdulrasool2014-06-131-9/+0
| | | | | | | | 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
* Remove unused variable.Greg Clayton2014-05-281-2/+0
| | | | llvm-svn: 209703
* Fixed the Symbol code to resolve the callable addressSean Callanan2014-05-231-23/+13
| | | | | | | | | | 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
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-38/+36
| | | | | | | 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
* cleanup unreferenced functionsSaleem Abdulrasool2014-03-201-37/+37
| | | | | | | | | | | | | 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
* Emit a warning diagnostic if a symbol was promotedSean Callanan2014-02-191-0/+4
| | | | | | | | | 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
* Fixed the AST importer to ensure that base classesSean Callanan2013-12-201-0/+2
| | | | | | | | | | | | | 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
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-7/+7
| | | | | | | | | | 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
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-7/+7
| | | | | | | | | | | | | | | | | | | | | 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
* <rdar://problem/14496092>Greg Clayton2013-10-311-5/+18
| | | | | | Fixes from code review by Jim Ingham that reinstate preferring an external vs non-external symbol when finding function addresses. llvm-svn: 193761
* <rdar://problem/14496092>Greg Clayton2013-10-301-22/+41
| | | | | | 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
* Fixes to get LLDB building on Windows again.Deepak Panickal2013-10-221-2/+2
| | | | llvm-svn: 193159
* <rdar://problem/14496092>Greg Clayton2013-10-211-16/+66
| | | | | | | | 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
* Remove a spurious comment.Jim Ingham2013-09-051-1/+0
| | | | llvm-svn: 190027
* clean up about 22 warnings messagesMichael Sartain2013-08-071-1/+1
| | | | llvm-svn: 187900
* Actually use the return value we get back whenSean Callanan2013-07-151-15/+10
| | | | | | | | | creating a persistent variable, rather than making a (potentially expensive) lookup by name. <rdar://problem/14337653> llvm-svn: 186337
* Huge change to clean up types.Greg Clayton2013-07-111-205/+143
| | | | | | | | 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
* Cleanup on the unified section list changes. Main changes are:Greg Clayton2013-07-101-7/+2
| | | | | | | | | | | | | | | - 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
* <rdar://problem/13893094>Greg Clayton2013-05-171-7/+1
| | | | | | Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression. llvm-svn: 182066
* Fixed a few obvious errors pointed out by the static analyzer.Jim Ingham2013-05-151-1/+1
| | | | llvm-svn: 181911
* Fixed a problem where the expression parser wouldSean Callanan2013-04-301-1/+1
| | | | | | | | | | give up if it couldn't find the address for the first symbol it found with a particular name and type. <rdar://problem/13748253> llvm-svn: 180764
* Fixed a crash when we tried dyn_cast<>ing aSean Callanan2013-04-271-0/+3
| | | | | | | | null pointer. <rdar://problem/13745684> llvm-svn: 180663
* Hardening to avoid null-pointer crashes in theSean Callanan2013-04-261-0/+6
| | | | | | | | presence of malformed class types. <rdar://problem/13740646> llvm-svn: 180645
* Fixed a problem where the expression parser wouldSean Callanan2013-04-241-4/+13
| | | | | | | | | | | | | | not find multiple functions with the same name but different types. Now we keep track of what types we've already reported for a function and only elide functions if we've already reported a conflicting one. Also added a test case. <rdar://problem/11367837> llvm-svn: 180167
* Removed 2800+ lines of code that no longer do anythingSean Callanan2013-04-191-1126/+0
| | | | | | | now that the IR interpreter and the JIT share the same materialization codepaths. llvm-svn: 179842
* After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton2013-04-181-6/+6
| | | | | | the macros and just use C++11. llvm-svn: 179805
* This commit changes the way LLDB executes userSean Callanan2013-04-181-8/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
OpenPOWER on IntegriCloud