summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression/IRInterpreter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Don't defend against internal LLVM errors in IRInterpreterRaphael Isemann2020-01-141-125/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Whenever we cast an LLVM instruction to one of its subclasses, we do a double check if the RTTI enum value actually allows us to cast the class. I don't see a way this can ever happen as even when LLVM's RTTI system has some corrupt internal state (which we probably should not test in the first place) we just reuse LLVM RTTI to do the second check. This also means that if we ever make an actual programming error in this function (e.g., have a enum value and then cast it to a different subclass), we just silently fall back to the JIT in our tests. We also can't test this code in any reasonable way. This removes the checks and uses `llvm::cast` instead which will raise a fatal error when casting fails. Reviewers: labath, mib Reviewed By: labath Subscribers: abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72596
* [lldb][NFC] Use range-based for loops in IRInterpreterRaphael Isemann2020-01-131-16/+12
|
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-176/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
* Get the expression parser to handle missing weak symbols.Jim Ingham2019-06-281-2/+3
| | | | | | | | | | MachO only for this patch. Differential Revision: https://reviews.llvm.org/D63914 <rdar://problem/51463642> llvm-svn: 364686
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-131-3/+3
| | | | | | | | | | | | | | | | | The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [opaque pointer types] Remove some calls to generic Type subtype accessors.James Y Knight2019-01-101-3/+0
| | | | | | | | | | | | That is, remove many of the calls to Type::getNumContainedTypes(), Type::subtypes(), and Type::getContainedType(N). I'm not intending to remove these accessors -- they are useful/necessary in some cases. However, removing the pointee type from pointers would potentially break some uses, and reducing the number of calls makes it easier to audit. llvm-svn: 350835
* Revert "[IRInterpreter] Minor cleanups, add comments. NFCI."Davide Italiano2018-09-171-3/+7
| | | | | | This breaks buildbots. llvm-svn: 342404
* [IRInterpreter] Minor cleanups, add comments. NFCI.Davide Italiano2018-09-141-7/+3
| | | | llvm-svn: 342280
* [IRInterpreter] Fall back to JIT with 128-bit values.Davide Italiano2018-09-141-0/+12
| | | | | | | | | | | | | They're not that common, and falling back is definitely better than throwing an error instead of the result. If we feel motivated, we might end up implementing support for these, but it's unclear whether it's worth the effort/complexity. Fixes PR38925. <rdar://problem/44436068> llvm-svn: 342262
* Allow IRInterpreter to deal with non-power-of-2 sized types to support some ↵Frederic Riss2018-08-281-11/+6
| | | | | | | | | | | | | | | | | | | | bitfield accesses. Summary: For some bitfield patterns (like the one added by this commit), Clang will generate non-regular data types like i24 or i48. This patch follows a pretty naive approach of just bumping the type size to the next power of 2. DataExtractor know how to deal with weird sizes. The operations on Scalar do not know how to deal with those types though, so we have to legalize the size when creating a Scalar. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D51245 llvm-svn: 340880
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-071-1/+1
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* IRInterpreter: fix sign extension of small types (pr37840)Pavel Labath2018-06-201-7/+1
| | | | | | | | | | | | | Sign-extension of small types (e.g. short) was not handled correctly. The reason for that was that when we were assigning the a value to the Scalar object, we would accidentally promote the type to int (even though the assignment code in AssignTypeToMatch tried to cast the value to the appropriate type, it would still invoke the "int" version of operator=). Instead, I use the APInt version of operator=, where the bitwidth is specified explicitly. Among other things, this allows us to fold the individual size cases into one. llvm-svn: 335114
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Do not use default arguments of DataLayout::getPointer*. NFCFangrui Song2017-12-061-5/+0
| | | | | | | | | | | | | | Summary: There are "FIXME"s in include/llvm/IR/DataLayout.h to remove the default arguments. Reviewers: zturner, clayborg Reviewed By: zturner Subscribers: bjope Differential Revision: https://reviews.llvm.org/D40064 llvm-svn: 319869
* Rename Error -> Status.Zachary Turner2017-05-121-19/+19
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-041-1/+1
| | | | llvm-svn: 296943
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Remove dependencies from Utility to Core and Target.Zachary Turner2017-02-141-1/+1
| | | | | | | | | | With this patch, the only dependency left is from Utility to Host. After this is broken, Utility will finally be standalone. Differential Revision: https://reviews.llvm.org/D29909 llvm-svn: 295088
* Move classes from Core -> Utility.Zachary Turner2017-02-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Make lldb -Werror clean for -Wstring-conversionDavid Blaikie2017-01-061-19/+17
| | | | | | | | | Also found/fixed one bug identified by this warning in RenderScriptx86ABIFixups.cpp where a string literal was being used in an effort to provide a name for an instruction/register, but was instead being passed as the bool 'isVolatile' parameter. llvm-svn: 291198
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-1663/+1527
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* [LLDB] Added support for PHI nodes to IR interpreterMarianne Mailhot-Sarrasin2016-05-121-1/+46
| | | | | | | | | | This allows expressions such as 'i == 1 || i == 2` to be executed using the IR interpreter, instead of relying on JIT code injection (which may not be available on some platforms). Patch by cameron314 Differential Revision: http://reviews.llvm.org/D19124 llvm-svn: 269340
* XFail TestLambdas.py on Windows after fixing some of the problemsAdrian McCarthy2016-05-041-3/+11
| | | | | | | | | | | | | | 1. Fixed semicolon placement in the lambda in the test itself. 2. Fixed lldbinline tests in general so that we don't attempt tests on platforms that don't use the given type of debug info. (For example, no DWO tests on Windows.) This fixes one of the two failures on Windows. (TestLambdas.py was the only inline test that wasn't XFailed or skipped on Windows.) 3. Set the error string in IRInterpreter::CanInterpret so that the caller doesn't print (null) instead of an explanation. I don't entirely understand the error, so feel free to suggest a better wording. 4. XFailed the test on Windows. The interpreter won't evaluate the lambda because the module has multiple function bodies. I don't exactly understand why that's a problem for the interpreter nor why the problem arises only on Windows. Differential Revision: http://reviews.llvm.org/D19606 llvm-svn: 268573
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-151-15/+26
| | | | | | | | | | | | | 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-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
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-191-18/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 bug with function resolution when using IR InterpreterTed Woodward2016-03-011-25/+39
| | | | | | | | | | | | 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
* 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
* [opaque pointer types] [NFC] Fix fallout from DataLayout::getIndexedOffset ↵Eduard Burtescu2016-01-221-3/+5
| | | | | | changes (rL258478). llvm-svn: 258481
* 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
* Fix off-by-one size check.Chaoren Lin2015-09-161-1/+1
| | | | llvm-svn: 247766
* Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a ↵Ewan Crawford2015-07-141-25/+252
| | | | | | | | | | | | | | | | | | | | 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
* remove trailing whitespace + remove some useless commentsSylvestre Ledru2014-07-061-231/+231
| | | | llvm-svn: 212411
* sanitise sign comparisonsSaleem Abdulrasool2014-04-021-1/+1
| | | | | | | | This is a mechanical change addressing the various sign comparison warnings that are identified by both clang and gcc. This helps cleanup some of the warning spew that occurs during builds. llvm-svn: 205390
* Added a missing "break" to avoid falling throughSean Callanan2014-03-251-0/+1
| | | | | | when other cases get added. llvm-svn: 204751
* Fixed the IRInterpreter to ignore call instructionsSean Callanan2014-03-251-0/+68
| | | | | | that call debug-information intrinsics. llvm-svn: 204750
* Implemented TruncInst in the IRInterpreter.Sean Callanan2013-10-111-0/+37
| | | | | | <rdar://problem/15188389> llvm-svn: 192489
* Use a StreamString to fix the endianness inSean Callanan2013-09-171-3/+10
| | | | | | | | constants before using them in the IR interpreter. Patch by Félix Cloutier. llvm-svn: 190877
* Fixed the IRInterpreter to reject any code thatSean Callanan2013-06-271-0/+14
| | | | | | | | | | | has more than one function with a body. This prevents declarations e.g. of blocks from being passed to the IRInterpreter; they must pass through to the JIT. <rdar://problem/14180236> llvm-svn: 185057
* Hardened the IR interpreter to prevent it fromSean Callanan2013-06-061-1/+1
| | | | | | | | reading non-standard value sizes. <rdar://problem/14081292> llvm-svn: 183448
* Fixes for the IR interpreter:Sean Callanan2013-06-051-8/+40
| | | | | | | | | | | | | | - Implemented the SExt instruction, and - eliminated redundant codepaths for constant handling. Added test cases. <rdar://problem/13244258> <rdar://problem/13955820> llvm-svn: 183344
* Fix various build warnings.Matt Kopec2013-06-031-8/+8
| | | | llvm-svn: 183140
* Fixed value evaluation to handle null constants.Sean Callanan2013-05-311-1/+5
| | | | | | <rdar://problem/14005311> llvm-svn: 183022
* Fixed signed operations in the IR interpreter.Sean Callanan2013-05-241-0/+12
| | | | | | | | Scalar now can make itself signed if needed. <rdar://problem/13977632> llvm-svn: 182668
* Since the IR interpreter does not (currently)Sean Callanan2013-05-021-0/+23
| | | | | | | | | | support operands with vector types, it now reports that it cannot interpret expressions that use vector types. They get sent to the JIT instead. <rdar://problem/13733651> llvm-svn: 180899
* Performance optimizations to ClangUserExpression,Sean Callanan2013-04-271-29/+11
| | | | | | | | | | | | | | | | | | | | mostly related to management of the stack frame for the interpreter. - First, if the expression can be interpreted, allocate the stack frame in the target process (to make sure pointers are valid) but only read/write to the copy in the host's memory. - Second, keep the memory allocations for the stack frame and the materialized struct as member variables of ClangUserExpression. This avoids memory allocations and deallocations each time the expression runs. <rdar://problem/13043685> llvm-svn: 180664
OpenPOWER on IntegriCloud