summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert r266311 - Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-26/+15
| | | | | | Try to get 32-bit build bots running again. llvm-svn: 266341
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-15/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+21
| | | | | | | | | | | | | | 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
* If the fixed expression doesn't parse, don't tell the user about it.Jim Ingham2016-04-061-0/+5
| | | | llvm-svn: 265495
* Don't write "using $_lldb_local_vars" statements for variables withJim Ingham2016-04-061-1/+1
| | | | | | | no name. These were showing up with a recent clang, I haven't tracked down why yet, but adding them is clearly wrong. llvm-svn: 265494
* Don't register the addresses of private symbols from expressions.Sean Callanan2016-03-301-1/+1
| | | | | | | | They're not supposed to go in the symbol table, and in fact the way the JIT is currently implemented it sometimes crashes when you try to get the address of such a function. So we skip them. llvm-svn: 264821
* Figure out what the fixed expression is, and print it. Added another target ↵Jim Ingham2016-03-293-16/+116
| | | | | | | | | | | | | 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
* Don't try to actually run code when the expression is top-level.Sean Callanan2016-03-281-0/+5
| | | | llvm-svn: 264660
* Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. ↵Jim Ingham2016-03-252-3/+4
| | | | | | | | | | | | | | | "." 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
* Collect IRExecutionUnits as part of persistent expression state.Sean Callanan2016-03-212-40/+215
| | | | | | | | | | | | | 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-213-5/+10
| | | | | | | | | | 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
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-198-143/+232
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix "ninja check-lldb" crash in IRExecutionUnit.cppTed Woodward2016-03-091-6/+16
| | | | | | | | | | | | | | | Summary: From Adrian McCarthy: "Running ninja check-lldb now has one crash in a Python process, due to deferencing a null pointer in IRExecutionUnit.cpp: candidate_sc.symbol is null, which leads to a call with a null this pointer." Reviewers: zturner, spyffe, amccarth Subscribers: ted, jingham, lldb-commits Differential Revision: http://reviews.llvm.org/D17860 llvm-svn: 263066
* Support floating point values in 128-bit SSE vector registersAdrian Prantl2016-03-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The System-V x86_64 ABI requires floating point values to be passed in 128-but SSE vector registers (xmm0, ...). When printing such a variable this currently yields an <invalid load address>. This patch makes LLDB's DWARF expression evaluator accept 128-bit registers as scalars. It also relaxes the check that the size of the result of the DWARF expression be equal to the size of the variable to a greater-than. DWARF defers to the ABI how smaller values are being placed in a larger register. Implementation note: I found the code in Value::SetContext() that changes the m_value_type after the fact to be questionable. I added a sanity check that the Value's memory buffer has indeed been written to (this is necessary, because we may have a scalar value in a vector register), but really I feel like this is the wrong place to be setting it. Reviewed by Greg Clayton. http://reviews.llvm.org/D17897 rdar://problem/24944340 llvm-svn: 262947
* Fix warning in IRExecutionUnit.cppPavel Labath2016-03-041-0/+2
| | | | llvm-svn: 262712
* Fix bug with function resolution when using IR InterpreterTed Woodward2016-03-013-27/+44
| | | | | | | | | | | | Summary: Recent changes to the expression parser broke function name resolution when using the IR interpreter instead of JIT. This patch changes the IRMemoryMap ivar in InterpreterStackFrame to an IRExecutionUnitSP (which is a subclass), allowing InterpreterStackFrame::ResolveConstantValue() to call FindSymbol() on the name of the Value when it's a FunctionVal. It also changes IRExecutionUnit::FindInSymbols() to call GetFileAddress() on the symball if ResolveCallableAddress() fails and there is no valid Process. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17745 llvm-svn: 262407
* DWARFExpression: Don't resolve load address in DW_OP_plusTamas Berghammer2016-03-011-3/+3
| | | | | | | | | If we have a TargetLoadAddress on the top of the DWARF stack then a DW_OP_plus or a DW_OP_plus_ucons sholudn't dereference (resolve) it and then add the value to the dereferenced value but it should offset the load address by the specified constant. llvm-svn: 262339
* Revert "Fix bug with register values byte order in expression evaluation."Todd Fiala2016-02-271-10/+3
| | | | | | | | | This reverts commit r262041, which caused asserts starting yesterday on the OS X testbot. See details in: https://llvm.org/bugs/show_bug.cgi?id=26758 llvm-svn: 262156
* Register value is not necessarily scalar.Chaoren Lin2016-02-261-261/+262
| | | | | | | | | | Reviewers: aidan.dodds, mamai Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17658 llvm-svn: 262081
* Fix bug with register values byte order in expression evaluation.Aidan Dodds2016-02-261-3/+9
| | | | | | | | | | The evaluation of expressions containing register values was broken for targets for which endianness differs from host. Committed on behalf of: mamai <marianne.mailhot.sarrasin@gmail.com> Differential revision: http://reviews.llvm.org/D17167 llvm-svn: 262041
* Revert part of rL262014 as it caused issues on gcc-i386Tamas Berghammer2016-02-261-4/+0
| | | | llvm-svn: 262023
* Add support for DW_OP_push_object_address in dwarf expressionsTamas Berghammer2016-02-261-4/+27
| | | | | | | | | Additionally fix the type of some dwarf expression where we had a confusion between scalar and load address types after a dereference. Differential revision: http://reviews.llvm.org/D17604 llvm-svn: 262014
* 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
* Fix TestCStrings for Linux with i386 inferiors.Chaoren Lin2016-02-241-48/+43
| | | | | | | | | | | | Summary: Temporarily revert part of r261704. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17557 llvm-svn: 261718
* When looking for symbols, find load addresses in a more robust way.Sean Callanan2016-02-231-36/+77
| | | | | | | | | | | | | | | | IRExecutionUnit previously replicated a bunch of logic that already existed elsewhere for the purpose of getting a load address for a symbol. This approach failed to resolve certain types of symbols. Instead, we now use functions on SymbolContext to do the address resolution. This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a latent bug where we looked at the wrong SymbolContext to determine whether or not it is external. <rdar://problem/24770829> llvm-svn: 261704
* 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
* Removed many JIT workarounds from IRForTarget.Sean Callanan2016-02-131-28/+31
| | | | | | | | | | | | | | | | | | | | | | 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
* Fix stripping of _ when looking for symbols in IRExecutionUnit.Sean Callanan2016-02-121-74/+18
| | | | | | | | | | | | | Previously we would try both versions of a symbol -- the one with _ in it and the one without -- in all cases, because we didn't know what the current platform's policy was. However, stripping _ is only necessary on platforms where _ is the prefix for global symbols. There's an API that does this, though, on llvm::DataLayout, so this patch fixes IRExecutionUnit to use that API to determine whether or not to strip _ from the symbol or not. llvm-svn: 260767
* IRInterpreter now recognizes expressions with constants it doesn't handle.Sean Callanan2016-02-121-0/+50
| | | | | | | | | | | | | If an instruction has a constant that IRInterpreter doesn't know how to deal with (say, an array constant, because we can't materialize it to APInt) then we used to ignore that and only fail during expression execution. This is annoying because if IRInterpreter had just returned false from CanInterpret(), the JIT would have been used. Now the IRInterpreter checks constants as part of CanInterpret(), so this should hopefully no longer be an issue. llvm-svn: 260735
* Centralized symbol lookup in IRExecutionUnit, and fixed the code model.Sean Callanan2016-02-121-67/+324
| | | | | | | | | | | | | 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
* Take 2: Use an artifical namespace so that member vars do not hide local vars.Siva Chandra2016-02-051-2/+31
| | | | | | | | | | | | 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-041-31/+2
| | | | | | | | | | | | | | 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-041-2/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove autoconf support from source directories.Eugene Zelenko2016-01-281-14/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* Revert r258546.Saleem Abdulrasool2016-01-261-1/+0
| | | | | | | | | Seems that the patch was rebased on top of another change which obsoleted the change but wasnt caught. Thanks to nbjoerg for pointing this out! llvm-svn: 258821
* Silence -Wreturn-type warningsSaleem Abdulrasool2016-01-221-0/+1
| | | | | | | | Address a couple of instances of -Wreturn-type warning from GCC. The switches are covered, add an llvm_unreachable to the end of the functions to silence the warning. NFC. llvm-svn: 258546
* Use "_$" prefix instead of "$" for dynamic checker function inserted by LLDB ↵Bhushan D. Attarde2016-01-221-2/+2
| | | | | | | | | | | | | | | during expression evaluation SUMMARY: The symbol "$" has a special meaning for MIPS i.e it is marker for temporary symbols for MIPS. So this patch uses additional _ prefix for "$__lldb_valid_pointer_check" so that it wont be marked as temporary symbol in case of MIPS. Reviewers: clayborg, spyffe Subscribers: dean, emaste, mohit.bhakkad, sagar, jaydeep, lldb-commits Differential http://reviews.llvm.org/D14111 llvm-svn: 258485
* [opaque pointer types] [NFC] Fix fallout from DataLayout::getIndexedOffset ↵Eduard Burtescu2016-01-221-3/+5
| | | | | | changes (rL258478). llvm-svn: 258481
* Placate MVSC after my last commit.Davide Italiano2016-01-191-2/+2
| | | | | | | | Zachary introduced the 'default' case explicitly to placate a warning in the Microsoft compiler but that broke clang with -Werror. The new code should keep both compilers happy. llvm-svn: 258212
* [Process] Remove dead code. All the switch cases are already covered.Davide Italiano2016-01-191-2/+0
| | | | llvm-svn: 258199
* Update for llvm change. NFC.Rafael Espindola2016-01-181-1/+1
| | | | llvm-svn: 258080
* Fix some compiler warnings with MSVC 2015.Zachary Turner2016-01-131-0/+2
| | | | llvm-svn: 257671
* Read macro info from .debug_macro section and use it for expression evaluation.Siva Chandra2015-12-161-1/+136
| | | | | | | | | | | | | | | | | Summary: DWARF 5 proposes a reinvented .debug_macro section. This change follows that spec. Currently, only GCC produces the .debug_macro section and hence the added test is annottated with expectedFailureClang. Reviewers: spyffe, clayborg, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15437 llvm-svn: 255729
* Fixed a bug where the size of a type was used instead of the size of a pointer.Sean Callanan2015-11-101-1/+1
| | | | llvm-svn: 252655
* Make lldb::endian::InlHostByteOrder() private.Bruce Mitchener2015-11-071-1/+1
| | | | | | | | | | | | | | | | | | Summary: Since this is within the lldb namespace, the compiler tries to export a symbol for it. Unfortunately, since it is inlined, the symbol is hidden and this results in a mess of warnings when building on OS X with cmake. Moving it to the lldb_private namespace eliminates that problem. Reviewers: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D14417 llvm-svn: 252396
* lldb/ADT: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-11-071-6/+6
| | | | | | | Remove implicit ilist iterator conversions before reapplying r252372 (which will disallow them). llvm-svn: 252378
* AddInitialArguments -> AddArguments, and we pass in the struct_address and ↵Jim Ingham2015-11-051-8/+4
| | | | | | | | | push it too. All the callers had to do this by hand and we ended up never actually adding initial arguments and then reusing them by passing in the struct address separately, so the distinction wasn't needed. llvm-svn: 252108
* Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. ↵Jim Ingham2015-11-044-13/+53
| | | | | | | | Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
* Add the ability to pass an EvaluateExpressionOptions when you make a ↵Jim Ingham2015-11-032-7/+17
| | | | | | | | UserExpression. This isn't used in this commit but will be in a future commit. llvm-svn: 251887
* Create an expression parser for Go.Ryan Brown2015-11-023-322/+363
| | | | | | | | | | | The Go interpreter doesn't JIT or use LLVM, so this also moves all the JIT related code from UserExpression to a new class LLVMUserExpression. Differential Revision: http://reviews.llvm.org/D13073 Fix merge llvm-svn: 251820
OpenPOWER on IntegriCloud