summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ExpressionParser
Commit message (Collapse)AuthorAgeFilesLines
* [fix] Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-292-5/+15
| | | | | | | | | | | | | | | | | | | In templated const functions, trying to run an expression would produce the error error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo' member declaration does not match because it is const qualified error: 1 error parsing expression which is no good. It turned out we don't actually need to worry about "const," we just need to be consistent about the declaration of the expression and the FunctionDecl we inject into the class for "this." Also added a test case. <rdar://problem/24985958> llvm-svn: 268083
* Revert "Fixed a bug where const this would cause parser errors about ↵Pavel Labath2016-04-282-15/+5
| | | | | | | | | | $__lldb_expr." This reverts commit r267833 as it breaks the build. It looks like some work in progress got committed together with the actual fix, but I'm not sure which one is which, so I'll revert the whole patch and let author resumbit it after fixing the build error. llvm-svn: 267861
* Fix an inefficiency in the handling of $__lldb_local_vars in expressions.Jim Ingham2016-04-282-1/+3
| | | | | | | | | | | | | | The code in ClangExpressionDeclMap::FindExternalVisibleDecls figures out what the token means, and adds the namespace to the lookup context, but since it doesn't mark it as special in the search context, we go on to pass the name $__lldb_local_vars to the ASTSource for further lookup. Unless we've done our job wrong, those lookups will always fail, but the can be costly. So I added a bit to m_found & use that to short-circuit the lookup. <rdar://problem/25613384> llvm-svn: 267842
* Fixed a bug where const this would cause parser errors about $__lldb_expr.Sean Callanan2016-04-282-5/+15
| | | | | | | | | | | | | | | | | | | In templated const functions, trying to run an expression would produce the error error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo' member declaration does not match because it is const qualified error: 1 error parsing expression which is no good. It turned out we don't actually need to worry about "const," we just need to be consistent about the declaration of the expression and the FunctionDecl we inject into the class for "this." Also added a test case. <rdar://problem/24985958> llvm-svn: 267833
* Expressions can run without a process.Jim Ingham2016-04-211-17/+30
| | | | | | | | | | | Code was added in ClangExpressionParser::ClangExpressionParser that was calling through the process w/o checking that it was good. Also, we were pretending that we could do something reasonable if we had no target, but that's actually not true, so I check for a target at the beginning of the constructor and don't make a compiler in that case. <rdar://problem/25841198> llvm-svn: 266944
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-151-1/+7
| | | | | | | | | | | | | Recommit modified version of r266311 including build bot regression fix. This differs from the original r266311 by: - Fixing Scalar::Promote to correctly zero- or sign-extend value depending on signedness of the *source* type, not the target type. - Omitting a few stand-alone fixes that were already committed separately. llvm-svn: 266422
* Revert r266311 - Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-7/+1
| | | | | | Try to get 32-bit build bots running again. llvm-svn: 266341
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Scalar implementation and a few other places in LLDB directly access the internal implementation of APInt values using the getRawData method. Unfortunately, pretty much all of these places do not handle big-endian systems correctly. While on little-endian machines, the pointer returned by getRawData can simply be used as a pointer to the integer value in its natural format, no matter what size, this is not true on big-endian systems: getRawData actually points to an array of type uint64_t, with the first element of the array always containing the least-significant word of the integer. This means that if the bitsize of that integer is smaller than 64, we need to add an offset to the pointer returned by getRawData in order to access the value in its natural type, and if the bitsize is *larger* than 64, we actually have to swap the constituent words before we can access the value in its natural type. This patch fixes every incorrect use of getRawData in the code base. For the most part, this is done by simply removing uses of getRawData in the first place, and using other APInt member functions to operate on the integer data. This can be done in many member functions of Scalar itself, as well as in Symbol/Type.h and in IRInterpreter::Interpret. For the latter, I've had to add a Scalar::MakeUnsigned routine to parallel the existing Scalar::MakeSigned, e.g. in order to implement an unsigned divide. The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong were already unused and can be simply removed. I've also removed the Scalar::GetRawBits64 function and its few users. The one remaining user of getRawData in Scalar.cpp is GetBytes. I've implemented all the cases described above to correctly implement access to the underlying integer data on big-endian systems. GetData now simply calls GetBytes instead of reimplementing its contents. Finally, two places in the clang interface code were also accessing APInt.getRawData in order to actually construct a byte representation of an integer. I've changed those to make use of a Scalar instead, to avoid having to re-implement the logic there. The patch also adds a couple of unit tests verifying correct operation of the GetBytes routine as well as the conversion routines. Those tests actually exposed more problems in the Scalar code: the SetValueFromData routine didn't work correctly for 128- and 256-bit data types, and the SChar routine should have an explicit "signed char" return type to work correctly on platforms where char defaults to unsigned. Differential Revision: http://reviews.llvm.org/D18981 llvm-svn: 266311
* Breakpoint conditions were making result variables, which they should not do. Jim Ingham2016-04-122-8/+9
| | | | | | | | | | | | | | The result variables aren't useful, and if you have a breakpoint on a common function you can generate a lot of these. So I changed the code that checks the condition to set ResultVariableIsInternal in the EvaluateExpressionOptions that we pass to the execution. Unfortunately, the check for this variable was done in the wrong place (the static UserExpression::Evaluate) which is not how breakpoint conditions execute expressions (UserExpression::Execute). So I moved the check to UserExpression::Execute (which Evaluate also calls) and made the overridden method DoExecute. llvm-svn: 266093
* The FixItList typedef should have been inside "class ClangDiagnostic".Jim Ingham2016-04-061-1/+2
| | | | llvm-svn: 265496
* Fix a crasher that could happen if ClangASTSource::CompleteType() found a ↵Greg Clayton2016-04-051-3/+3
| | | | | | | | type whose name matched, but came from a different language. We need to verify that any types we find are clang types before trying to extra a clang::QualType and then use it. <rdar://problem/24138711> llvm-svn: 265443
* Fix header name.Jim Ingham2016-03-301-1/+1
| | | | llvm-svn: 264883
* Fix warning in ClangExpressionParserPavel Labath2016-03-301-1/+1
| | | | llvm-svn: 264847
* Figure out what the fixed expression is, and print it. Added another target ↵Jim Ingham2016-03-291-33/+21
| | | | | | | | | | | | | setting to quietly apply fixits for those who really trust clang's fixits. Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present. <rdar://problem/25351938> llvm-svn: 264793
* Move some functions from DWARFASTParserClang to ClangASTImporter.Zachary Turner2016-03-283-22/+17
| | | | | | | | | | | | | | | | | | This allows these functions to be re-used by a forthcoming PDBASTParser. The functions in question are CanCompleteType, CompleteType, and CanImport. Conceptually, these functions belong on ClangASTImporter anyway, and previously they were just ping ponging around through a few levels of indirection to end up there as well, so this patch actually makes the code somewhat simpler. A few methods were moved to a new file called ClangUtil, so that they can be shared between ClangASTImporter and ClangASTContext without creating a circular dependency between those two cpp files. Differential Revision: http://reviews.llvm.org/D18381 llvm-svn: 264685
* Removed an override of LookupSymbol that mistakenly disabled it for Clang.Sean Callanan2016-03-281-3/+0
| | | | llvm-svn: 264659
* Record all translation units with more than one function in them (e.g., blocks).Sean Callanan2016-03-261-3/+9
| | | | | | | | | | | Blocks and lambdas have their implementation functions stored in the IR for an expression. If we put the block/lambda into a result variable it needs to stay around. As a heuristic, remember any execution unit that has more than one function in it. <rdar://problem/22864976> llvm-svn: 264483
* Removed LoggingDiagnosticConsumer, an unused class.Sean Callanan2016-03-251-50/+0
| | | | llvm-svn: 264478
* Fix now-ambiguous references to Error.Lang Hames2016-03-251-5/+5
| | | | llvm-svn: 264449
* Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. ↵Jim Ingham2016-03-254-12/+215
| | | | | | | | | | | | | | | "." for "->".) This feature is controlled by an expression command option, a target property and the SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions, those you have to get right when you make them. This is just a first stage. At present the fixits are applied silently. The next step is to tell the user about the applied fixit. <rdar://problem/25351938> llvm-svn: 264379
* Ignore global constructor warning in clang.Greg Clayton2016-03-241-0/+4
| | | | llvm-svn: 264361
* Backend support for top-level Clang epxressionsSean Callanan2016-03-228-210/+372
| | | | | | | | | | | | | | | | | | This patch adds a new ExecutionPolicy, eExecutionPolicyTopLevel, which tells the expression parser that the expression should be JITted as top level code but nothing (except static initializers) should be run. I have modified the Clang expression parser to recognize this execution policy. On top of the existing patches that support storing IR and maintaining a map of arbitrary Decls, this is mainly just patching up a few places in the expression parser. I intend to submit a patch for review that exposes this functionality through the "expression" command and through the SB API. That patch also includes a testcase for all of this. <rdar://problem/22864976> llvm-svn: 264095
* Collect IRExecutionUnits as part of persistent expression state.Sean Callanan2016-03-212-0/+115
| | | | | | | | | | | | | IRExecutionUnits contain code and data that persistent declarations can depend on. In order to keep them alive and provide for lookup of these symbols, we now allow any PersistentExpressionState to keep a list of execution units. Then, when doing symbol lookup on behalf of an expression, any IRExecutionUnit can consult the persistent expression states on a particular Target to find the appropriate symbol. <rdar://problem/22864976> llvm-svn: 263995
* Compilation can end up calling functions (e.g. to resolve indirect ↵Jim Ingham2016-03-212-2/+13
| | | | | | | | | | functions) so I added a way for compilation to take a "thread to use for compilation". If it isn't set then the compilation will use the currently selected thread. This should help keep function execution to the one thread intended. llvm-svn: 263972
* Handle any persistent Decl in the Clang expression parser, not just types.Sean Callanan2016-03-194-55/+82
| | | | | | | | | | Persistent decls have traditionally only been types. However, we want to be able to persist more things, like functions and global variables. This changes some of the nomenclature and the lookup rules to make this possible. <rdar://problem/22864976> llvm-svn: 263864
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-1910-144/+221
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to do a better job presenting errors that occur when evaluating expressions. Key to this effort is getting away from a model where all errors are spat out onto a stream where the client has to take or leave all of them. To this end, this patch adds a new class, DiagnosticManager, which contains errors produced by the compiler or by LLDB as an expression is created. The DiagnosticManager can dump itself to a log as well as to a string. Clients will (in the future) be able to filter out the errors they're interested in by ID or present subsets of these errors to the user. This patch is not intended to change the *users* of errors - only to thread DiagnosticManagers to all the places where streams are used. I also attempt to standardize our use of errors a bit, removing trailing newlines and making clients omit 'error:', 'warning:' etc. and instead pass the Severity flag. The patch is testsuite-neutral, with modifications to one part of the MI tests because it relied on "error: error:" being erroneously printed. This patch fixes the MI variable handling and the testcase. <rdar://problem/22864976> llvm-svn: 263859
* Revert "Track expression language from one place in ClangExpressionParser"Ewan Crawford2016-03-102-9/+9
| | | | | | r263099 seems to have broken some OSX tests llvm-svn: 263107
* Track expression language from one place in ClangExpressionParserEwan Crawford2016-03-102-9/+9
| | | | | | | | | | The current expression language is currently tracked in a few places within the ClangExpressionParser constructor. This patch adds a private lldb::LanguageType attribute to the ClangExpressionParser class and tracks the expression language from that one place. Author: Luke Drummond <luke.drummond@codeplay.com> Differential Revision: http://reviews.llvm.org/D17719 llvm-svn: 263099
* Update after r262737 in clang changed the accessor.James Y Knight2016-03-041-1/+1
| | | | llvm-svn: 262739
* remove unused local string in IRForTarget.cppAidan Dodds2016-02-261-2/+0
| | | | | | | | Committed on behalf of: ldrumm <luke.drummond@codeplay.com> Differential revision: http://reviews.llvm.org/D16412 llvm-svn: 262043
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-261-0/+1
| | | | | | the right thing and break. llvm-svn: 261950
* Improve readability and performance of ↵Aidan Dodds2016-02-251-5/+4
| | | | | | | | | | ClangExpressionParser::FindFunctionInModule Committed on behalf of: Luke Drummond Differential Revision: http://reviews.llvm.org/D17274 llvm-svn: 261861
* refactor/cleanup ClangExpressionParser::ParseEwan Crawford2016-02-191-33/+20
| | | | | | | | | | | | | | | This patches does the following: + fix return type: ClangExpressionParser::Parse returns unsigned, but was actually returning a signed value, num_errors. + use helper clang::TextDiagnosticBuffer::getNumErrors() instead of counting the errors ourself. + limit scoping of block-level automatic variables as much as practical. + remove reused multipurpose TextDiagnosticBuffer::const_iterator in favour of loop-scoped err, warn, and note variables in the diagnostic printing code. + refactor diagnostic printing loops to use a proper loop invariant. Author: Luke Drummond <luke.drummond@codeplay.com> Differential Revision: http://reviews.llvm.org/D17273 llvm-svn: 261345
* Delete unused function in ClangExpressionParserEwan Crawford2016-02-191-15/+0
| | | | | | | | | | | | [git 65dafa83] introduced the GetBuiltinIncludePath function copied from cfe/lib/Driver/CC1Options.cpp This function is no longer used in lldb's expression parser and I believe it is safe to remove it. Author: Luke Drummond <luke.drummond@codeplay.com> Differential Revision: http://reviews.llvm.org/D17266 llvm-svn: 261328
* [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation ↵Bhushan D. Attarde2016-02-181-4/+14
| | | | | | | | | | | | | | | for MIPS SUMMARY: This patch implements ArchSpec::GetClangTargetCPU() that provides string representing current architecture as a target CPU. This string is then passed to tools like clang so that they generate correct code for that target. Reviewers: clayborg, zturner Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits Differential Revision: http://reviews.llvm.org/D17022 llvm-svn: 261206
* Add -Wimplicit-fallthrough command line option to clang inJason Molenda2016-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the xcode project file to catch switch statements that have a case that falls through unintentionally. Define LLVM_FALLTHROUGH to indicate instances where a case has code and intends to fall through. This should be in llvm/Support/Compiler.h; Peter Collingbourne originally checked in there (r237766), then reverted (r237941) because he didn't have time to mark up all the 'case' statements that were intended to fall through. I put together a patch to get this back in llvm http://reviews.llvm.org/D17063 but it hasn't been approved in the past week. I added a new lldb-private-defines.h to hold the definition for now. Every place in lldb where there is a comment that the fall-through is intentional, I added LLVM_FALLTHROUGH to silence the warning. I haven't tried to identify whether the fallthrough is a bug or not in the other places. I haven't tried to add this to the cmake option build flags. This warning will only work for clang. This build cleanly (with some new warnings) on macosx with clang under xcodebuild, but if this causes problems for people on other configurations, I'll back it out. llvm-svn: 260930
* ExpressionParser: silence some GCC warningsSaleem Abdulrasool2016-02-152-2/+2
| | | | | | | Silence a -Wreorder warning about order of member initialization and a -Wqual-cast warning about casting away constness. NFC. llvm-svn: 260868
* Removed many JIT workarounds from IRForTarget.Sean Callanan2016-02-134-985/+58
| | | | | | | | | | | | | | | | | | | | | | Since IRExecutionUnit is now capable of looking up symbols, and the JIT is up to the task of generating the appropriate relocations, we don't need to do all the work that IRForTarget used to do to fixup symbols at the IR level. We also don't need to allocate data manually (with its attendant bugs) because the JIT is capable of doing so without crashing. We also don't need the awkward lldb.call.realName metadata to determine what calls are objc_msgSend, because they now just reference objc_msgSend. To make this work, we ensure that we recognize which symbols are extern "C" and report them to the compiler as such. We also report the full Decl of functions rather than just making up top-level functions with the appropriate types. This should not break any testcases, but let me know if you run into any issues. <rdar://problem/22864926> llvm-svn: 260768
* Centralized symbol lookup in IRExecutionUnit, and fixed the code model.Sean Callanan2016-02-121-0/+12
| | | | | | | | | | | | | I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a dreadful hack working around no-longer-existing JIT bugs. Thanks to our contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have, so I've cleaned them up a bit and moved them over to IRExecutionUnit. Also for historical reasons, IRExecutionUnit used the "Small" code model on non- ELF platforms (namely, OS X). That's no longer necessary, and we can use the same code model as everyone else on OS X. I've fixed that. llvm-svn: 260734
* Now that SymbolFileDWARF supports having types in completely separate .pcm ↵Greg Clayton2016-02-102-4/+8
| | | | | | | | | | | | | | file with "-fmodules -gmodules", each SymbolFileDWARF can reference module DWARF info by looking in other DWARF files. Then if you have 1000 .o files that each reference one or more .pcm files in their debug info, a simple Module::FindTypes(...) call can end up searching the same .pcm file over and over and over. Now all internal FindTypes methods in classes (ModuleList, Module, SymbolFile) now take an extra argument: llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries. This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files. <rdar://problem/24581488> llvm-svn: 260434
* Take 2: Use an artifical namespace so that member vars do not hide local vars.Siva Chandra2016-02-052-4/+67
| | | | | | | | | | | | Summary: This relands r259810 with fix for failures on Mac. Reviewers: spyffe, tfiala Subscribers: tfiala, lldb-commits Differential Revision: http://reviews.llvm.org/D16900 llvm-svn: 259902
* Revert "Use an artifical namespace so that member vars do not hide local vars."Siva Chandra2016-02-042-67/+4
| | | | | | | | | | | | | | Summary: This reverts commit 8af14b5f9af68c31ac80945e5b5d56f0a14b38e4. Reverting as it breaks a few tests on Mac. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16895 llvm-svn: 259823
* Use an artifical namespace so that member vars do not hide local vars.Siva Chandra2016-02-042-4/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While evaluating expressions when stopped in a class method, there was a problem of member variables hiding local variables. This was happening because, in the context of a method, clang already knew about member variables with their name and assumed that they were the only variables with those names in scope. Consequently, clang never checks with LLDB about the possibility of local variables with the same name and goes wrong. This change addresses the problem by using an artificial namespace "$__lldb_local_vars". All local variables in scope are declared in the "$__lldb_expr" method as follows: using $__lldb_local_vars::<local var 1>; using $__lldb_local_vars::<local var 2>; ... This hides the member variables with the same name and forces clang to enquire about the variables which it thinks are declared in $__lldb_local_vars. When LLDB notices that clang is enquiring about variables in $__lldb_local_vars, it looks up local vars and conveys their information if found. This way, member variables do not hide local variables, leading to correct evaluation of expressions. A point to keep in mind is that the above solution does not solve the problem for one specific case: namespace N { int a; } class A { public: void Method(); int a; }; void A::Method() { using N::a; ... // Since the above solution only touches locals, it does not // force clang to enquire about "a" coming from namespace N. } Reviewers: clayborg, spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16746 llvm-svn: 259810
* Add ability to override JIT expr compiler options.Aidan Dodds2016-02-031-25/+78
| | | | | | | | | Runtimes should be able to pass custom compilation options to the JIT for their stack frame. This patch adds a custom expression options member class to LanguageOptions, and modifies the clang expression evaluator to check the current runtime for those options. If those options are available on the runtime, they are passed to the clang compiler. Committed for Luke Drummond. Differential Revision: http://reviews.llvm.org/D15527 llvm-svn: 259644
* Fix build after clang interface change in r259489Pavel Labath2016-02-021-3/+3
| | | | llvm-svn: 259494
* Revert "fix up missing header from change r259084."Todd Fiala2016-01-291-1/+0
| | | | | | | | This change was made based on a bad signal from the Green Dragon LLDB builder. This change was not needed. Reverting out r259114. llvm-svn: 259216
* fix up missing header from change r259084.Todd Fiala2016-01-281-0/+1
| | | | llvm-svn: 259114
* Remove autoconf support from source directories.Eugene Zelenko2016-01-282-28/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* Fix build after rL259070.Chaoren Lin2016-01-281-1/+1
| | | | llvm-svn: 259086
* Update lldb for API change in clang r259070.Manman Ren2016-01-281-1/+1
| | | | llvm-svn: 259084
OpenPOWER on IntegriCloud