summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression
Commit message (Collapse)AuthorAgeFilesLines
...
* Update lldb's ExternalASTSources to match Clang r244161.Richard Smith2015-08-061-19/+14
| | | | llvm-svn: 244194
* 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
* Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a ↵Ewan Crawford2015-07-144-28/+283
| | | | | | | | | | | | | | | | | | | | function call on target via register manipulation For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support. Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls. In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation. To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter. The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values. Reviewers: jingham, spyffe Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427 Differential Revision: http://reviews.llvm.org/D9404 llvm-svn: 242137
* 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
* Make many mangled functions that might demangle a name be allowed to specify ↵Greg Clayton2015-07-082-3/+3
| | | | | | 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
* Fixed the C modules test case on Darwin by streamlining its code.Sean Callanan2015-07-081-28/+15
| | | | | | | | | | We don't need to do the fancy dance with checking whether the iterator represents a #define -- in fact, that's the wrong thing to do. The thing to do is check whether the highest-priority module that did something to the module #defined or #undefd it. If it #defined it, then the MacroInfo* will be non-NULL and we're good to go. llvm-svn: 241651
* Make sure we can lookup re-exported symbols after recent changes to ↵Greg Clayton2015-07-021-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb_private::Symbol. Recently lldb_private::Symbol was changed so the old code: Address &Symbol::GetAddress(); Is now: Address Symbol::GetAddress(); And the Address object that is returned will be invalid for non-address based symbols. When we have re-exported symbols this code would now fail: const Address sym_address = sym_ctx.symbol->GetAddress(); if (!sym_address.IsValid()) continue; symbol_load_addr = sym_ctx.symbol->ResolveCallableAddress(*target_sp); if (symbol_load_addr == LLDB_INVALID_ADDRESS) { symbol_load_addr = sym_address.GetLoadAddress(target_sp.get()); } It used to return an Address reference to the value of the re-exported symbol that contained no section and a zero value for Address.m_offset (since the original symbol in the symbol table had a value of zero). When a reference was returned, this meant the "sym_address.IsValid()" would return true because the Address.m_offset was not LLDB_INVALID_ADDRESS, it was zero. This was working by mistake. The Symbol::ResolveCallableAddress(...) actually checks for reexported symbols and whole bunch of other cases and resolves the address correctly, so we should let it do its thing and not cut it off before it can resolve the address with the "if (!sym_address.IsValid()) continue;". llvm-svn: 241282
* Fix typo in comment.Dawn Perchik2015-07-011-1/+1
| | | | llvm-svn: 241173
* Rename ClangUserExpression members to avoid confusion with language.Dawn Perchik2015-07-011-17/+17
| | | | | | | | The new names clarify that the members have to do with the execution context and not the language. For example, m_cplusplus was renamed to m_in_cplusplus_method. llvm-svn: 241132
* Fix LLDB build after r241035Tamas Berghammer2015-06-301-0/+2
| | | | llvm-svn: 241050
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-253-68/+65
| | | | | | | | | | | | | | | 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-182-3/+3
| | | | | | No functional change. llvm-svn: 239995
* Revert "Introduce a TypeSystem interface to support adding non-clang languages."Pavel Labath2015-06-085-60/+45
| | | | | | 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-085-45/+60
| | | | | | | | | | | | | 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-291-2/+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
* If we see an external function in the symbols, makeSean Callanan2015-05-282-28/+16
| | | | | | | | | | 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 crash if we don't have a process and needSean Callanan2015-05-281-10/+13
| | | | | | to check for alternate manglings. llvm-svn: 238475
* Allow expresions to have unique expression prefixes:Greg Clayton2015-05-271-1/+16
| | | | | | | | | | | | | | | | | | expr_options = lldb.SBExpressionOptions() expr_options.SetPrefix(''' struct Foo { int a; int b; int c; } ''' expr_result = frame.EvaluateExpression ("Foo foo = { 1, 2, 3}; foo", expr_options) This fixed a current issue with ptr_refs, cstr_refs and malloc_info so that they can work. If expressions define their own types and then return expression results that use those types, those types get copied into the target's AST context so they persist and the expression results can be still printed and used in future expressions. Code was added to the expression parser to copy the context in which types are defined if they are used as the expression results. So in the case of types defined by expressions, they get defined in a lldb_expr function and that function and _all_ of its statements get copied. Many types of statements are not supported in this copy (array subscript, lambdas, etc) so this causes expressions to fail as they can't copy the result types. To work around this issue I have added code that allows expressions to specify an expression specific prefix. Then when you evaluate the expression you can pass the "expr_options" and have types that can be correctly copied out into the target. I added this as a way to work around an issue, but I also think it is nice to be allowed to specify an expression prefix that can be reused by many expressions, so this feature is very useful. <rdar://problem/21130675> llvm-svn: 238365
* Don't allow infininte recursion when trying to resolve re-exported symbols.Greg Clayton2015-05-151-0/+5
| | | | | | <rdar://problem/20821289> llvm-svn: 237477
* Fixed a ton of gcc compile warningsVince Harron2015-05-131-1/+4
| | | | | | | | | | Removed some unused variables, added some consts, changed some casts to const_cast. I don't think any of these changes are very controversial. Differential Revision: http://reviews.llvm.org/D9674 llvm-svn: 237218
* Fix ClangUserExpression::Evaluate return code in case of eExpressionParseErrorIlia K2015-05-071-2/+3
| | | | | | | | | | | | | | Summary: This patch fixes retvalue of ClangUserExpression::Evaluate in case of eExpressionParseError error Reviewers: jingham, spyffe, clayborg Reviewed By: clayborg Subscribers: lldb-commits, clayborg, spyffe, jingham Differential Revision: http://reviews.llvm.org/D9502 llvm-svn: 236700
* Added support for locating and importing functionsSean Callanan2015-05-012-0/+67
| | | | | | | | | | | | (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
* Updated our use of clang::Preprocessor to reflectSean Callanan2015-05-011-1/+1
| | | | | | a change in the API used to get macros. llvm-svn: 236292
* Made macros from modules be injected before ourSean Callanan2015-04-302-40/+64
| | | | | | | | | | | global convenience expression prefix. Also ensured that if macros are defined by the modules we don't try to redefine them. Finally cleaned up a bit of code while I was in there. <rdar://problem/20756642> llvm-svn: 236266
* Fix build after Clang API change in r236176.Richard Smith2015-04-291-11/+4
| | | | llvm-svn: 236182
* Fix build.Chaoren Lin2015-04-231-1/+1
| | | | llvm-svn: 235653
* Fix build of lldb after clang r235614.Richard Smith2015-04-231-2/+2
| | | | llvm-svn: 235631
* This patch implements several improvements to theSean Callanan2015-04-203-26/+286
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | module-loading support for the expression parser. - It adds support for auto-loading modules referred to by a compile unit. These references are currently in the form of empty translation units. This functionality is gated by the setting target.auto-import-clang-modules (boolean) = false - It improves and corrects support for loading macros from modules, currently by textually pasting all #defines into the user's expression. The improvements center around including only those modules that are relevant to the current context - hand-loaded modules and the modules that are imported from the current compile unit. - It adds an "opt-in" mechanism for all of this functionality. Modules have to be explicitly imported (via @import) or auto-loaded (by enabling the above setting) to enable any of this functionality. It also adds support to the compile unit and symbol file code to deal with empty translation units that indicate module imports, and plumbs this through to the CompileUnit interface. Finally, it makes the following changes to the test suite: - It adds a testcase that verifies that modules are automatically loaded when the appropriate setting is enabled (lang/objc/modules-auto-import); and - It modifies lanb/objc/modules-incomplete to test the case where a module #undefs something that is #defined in another module. <rdar://problem/20299554> llvm-svn: 235313
* Added support to ClangUserExpression for importingSean Callanan2015-04-142-4/+159
| | | | | | | | | | | | | all the macros from the modules the user has loaded. These macros are currently imported textually into the expression's source code, which turns out not to impose the horrific string processing overhead that I thought it would, but I still plan to look into performance improvements. Also modified TestCModules to test that this works. llvm-svn: 234922
* Updated IRForTarget to change the way we generateSean Callanan2015-04-141-2/+4
| | | | | | | | | | | | relocations. We used to do GEP on a pointer to the result type, which is wrong. We should be doing GEP on a pointer to char, which allows us to offset correctly. This fixes the C modules testcase, so it's no longer ExpectFail. llvm-svn: 234918
* [IRForTarget] Strenghten handling of alternate mangling.Siva Chandra2015-04-091-26/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes an issue with GCC generated binaries wherein an expression with method invocations on std::string variables was failing. Such use cases are tested in TestSTL (albeit, in a test marked with @unittest2.expectedFailure because of other reasons). The reason for this particular failure with GCC is that the generated DWARF for std::basic_string<...> is incomplete, which makes clang not to use the alternate mangling scheme. GCC correctly generates the name of basic_string<...>: DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >" It also lists the template parameters of basic_string correctly: DW_TAG_template_type_parameter DW_AT_name "_CharT" DW_AT_type <0x0000009c> DW_TAG_template_type_parameter DW_AT_name "_Traits" DW_AT_type <0x00000609> DW_TAG_template_type_parameter DW_AT_name "_Alloc" DW_AT_type <0x000007fb> However, it does not list the template parameters of std::char_traits<>. This makes Clang feel (while parsing the expression) that the string variable is not actually a basic_string instance, and consequently does not use the alternate mangling scheme. Test Plan: dotest.py -C gcc -p TestSTL -- See it go past the "for" loop expression successfully. Reviewers: clayborg, spyffe Reviewed By: clayborg, spyffe Subscribers: tberghammer, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8846 llvm-svn: 234522
* Fix resolution of certain recursive types.Stephane Sezer2015-04-081-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a struct type S has a member T that has a member that is a function that returns a typedef of S* the respective field would be duplicated, which caused an assert down the line in RecordLayoutBuilder. This patch adds a check that removes the possibility of trying to resolve the same type twice within the same callstack. This commit also adds unit tests for these failures. Fixes https://llvm.org/bugs/show_bug.cgi?id=20486. Patch by Cristian Hancila. Test Plan: Run unit tests. Reviewers: clayborg spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8561 llvm-svn: 234441
* Fix -Wformat-pedantic warningsDavid Blaikie2015-04-082-3/+3
| | | | llvm-svn: 234429
* Fixed a problem where the second @import statementSean Callanan2015-04-071-2/+2
| | | | | | | | | | | | in a session would be silently ignored by the compiler because the compiler looked at its SourceLocation and decided it had already handled it. Also updated the relevant test case. <rdar://problem/20315447> llvm-svn: 234330
* Fixed a crash because we weren't generatingSean Callanan2015-04-061-3/+4
| | | | | | | | type-safe relocations against @reloc_placeholder. <rdar://problem/20438754> llvm-svn: 234260
* 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
* Added a testcase that covers loading a module andSean Callanan2015-04-031-0/+12
| | | | | | | | | | | verifying that the types from that module don't override types from DWARF. Also added a target setting to LLDB so we can tell Clang where to look for these local modules. <rdar://problem/18805055> llvm-svn: 234016
* Fix error resulting from llvm r233938.Zachary Turner2015-04-021-1/+1
| | | | llvm-svn: 233942
* Fix type detection for 'char' variablesTamas Berghammer2015-03-311-0/+3
| | | | | | | | | | | | A char can have signed and unsigned encoding but previously lldb always assumed it is signed. This CL adds a logic to detect the encoding of 'char' types based on the default encoding on the target architecture. It fixes variable printing and expression evaluation on architectures where 'char' is signed by default. Differential revision: http://reviews.llvm.org/D8636 llvm-svn: 233682
* Fix build broken by missing `typename` keyword.Zachary Turner2015-03-241-2/+3
| | | | llvm-svn: 233106
* Fix error introduced by changing function signatures.Zachary Turner2015-03-241-30/+46
| | | | | | | | | | | | | | | | | 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-49/+35
| | | | | | | | | | | | | | | | | 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
* Move lldb-log.cpp to core/Logging.cppZachary Turner2015-03-182-2/+1
| | | | | | | | | So that we don't have to update every single #include in the entire codebase to #include this new header (which used to get included by lldb-private-log.h, we automatically #include "Logging.h" from within "Log.h". llvm-svn: 232653
* Added nullptr to fix buildVince Harron2015-03-161-2/+3
| | | | llvm-svn: 232345
* 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
* Add support for the DWARFv3 (circa 2005) DW_OP_form_tls_addressJason Molenda2015-03-051-4/+13
| | | | | | | | | | | | | operator in addition to the vendor-extension DW_OP_GNU_push_tls_address. clang on PS4 and Darwin will be emitting the standard opcode as of r231286 via http://reviews.llvm.org/D8018 Behavior of this standard opcode is the same as DW_OP_GNU_push_tls_address. <rdar://problem/20043195> llvm-svn: 231342
* Don't #include clang headers from BreakpointLocation.hZachary Turner2015-03-041-2/+2
| | | | llvm-svn: 231263
* Don't #include FormatManager.h from Debugger.hZachary Turner2015-03-032-0/+5
| | | | | | | | Debugger.h is a huge file that gets included everywhere, and FormatManager.h brings in a ton of unnecessary stuff and doesn't even use anything from it in the header. llvm-svn: 231161
* Don't #include ClangPersistentVariables.h from Process.hZachary Turner2015-03-033-0/+3
| | | | | | | Nothing from this header file was even being referenced in Process.h anyway, so it was a completely unnecessary include. llvm-svn: 231131
OpenPOWER on IntegriCloud