summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Fix ARM32 inferior callsJan Kratochvil2019-12-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()' Actual: error: Expression can't be run, because there is no JIT compiled function Expected: <nothing, sync() has been executed> This patch has been checked by: D71707: clang-tidy: new bugprone-pointer-cast-widening https://reviews.llvm.org/D71707 Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended: echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out <stdin>: In function ‘main’: <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000 With debug output: Actual: IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3) Code can be run in the target. Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv Sections: [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text) ... HandleCommand, command did not succeed error: Expression can't be run, because there is no JIT compiled function Expected: IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3) IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060]. Code can be run in the target. Found function, has local address 0xb6fac000 and remote address 0xb6ff9020 Function's code range is [0xb6ff9020+0x40] ... Function data has contents: 0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1 ... Function disassembly: 0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr} Differential revision: https://reviews.llvm.org/D71498
* [lldb][NFC] Remove unused MaterializeInitializer and MaterializeInternalVariableRaphael Isemann2019-08-171-65/+0
| | | | llvm-svn: 369198
* Revert "[lldb] Reinstate original guard variable check"Raphael Isemann2019-08-141-5/+9
| | | | | | | | | | | It seems this breaks the following tests: lldb-Suite :: expression_command/call-function/TestCallUserDefinedFunction.py lldb-Suite :: expression_command/rdar42038760/TestScalarURem.py Let's revert this patch and wait until we find an actual issue that could be fixed by also doing the guard variable check on Windows. llvm-svn: 368920
* [lldb] Reinstate original guard variable checkRaphael Isemann2019-08-141-9/+5
| | | | | | | | | | The isGuardVariableSymbol option for ignoring Microsoft's ABI was originally added to get the bots green, but now that we found the actual issue (that we checked for prefix instead of suffix in the MS ABI check), we should be able to properly implement the guard variable check without any strange Microsoft exceptions. llvm-svn: 368802
* [Symbol] Decouple clang from CompilerTypeAlex Langford2019-08-131-2/+4
| | | | | | | | | | Summary: Ideally CompilerType would have no knowledge of clang or any individual TypeSystem. Decoupling clang is relatively straightforward. Differential Revision: https://reviews.llvm.org/D66102 llvm-svn: 368741
* [lldb] Fix Microsoft guard variable detectionRaphael Isemann2019-08-131-1/+1
| | | | | | | Apparently we need to check for a suffix, not a prefix. This broke probably broke expression evaluation on Windows. llvm-svn: 368695
* [lldb] Reland "Refactor guard variable checks in IRForTarget"Raphael Isemann2019-08-131-14/+19
| | | | | | | | It seems the broken guard variable check for Windows was a feature(TM) and not a bug, so let's keep add a flag to the guard check that keeps the old behavior in the places where we ignored guard variables before. llvm-svn: 368688
* [CompilerType] Pass an ExecutionContextScope to GetTypeBitAlign.Davide Italiano2019-08-121-1/+1
| | | | llvm-svn: 368620
* Revert "[lldb] Refactor guard variable checks in IRForTarget"Stella Stamenova2019-08-121-12/+12
| | | | | | This reverts commit 94fbbf712e906464f5f3abbeabcfcbc05d5352ec. llvm-svn: 368616
* Revert "[lldb] Fix dynamic_cast by no longer failing on variable without ↵Stella Stamenova2019-08-121-1/+7
| | | | | | | | metadata" This reverts commit b448d1bf212219febbb182d00c210bad1bd25e7f. llvm-svn: 368615
* [Symbol] GetTypeBitAlign() should return None in case of failure.Davide Italiano2019-08-121-2/+4
| | | | | | | | | | | | | | | | Summary: And not `zero`. This is the last API needed to be converted to an Optional<T>. Reviewers: xiaobai, compnerd Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66093 llvm-svn: 368614
* [lldb] Fix dynamic_cast by no longer failing on variable without metadataRaphael Isemann2019-08-101-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Our IR rewriting infrastructure currently fails when it encounters a variable which has no metadata associated. This causes dynamic_cast to fail as in this case IRForTarget considers the type info pointers ('@_ZTI...') to be variables without associated metadata. As there are no variables for these internal variables, this is actually not an error and dynamic_cast would work fine if we didn't throw this error. This patch fixes this by removing this diagnostics code. In case we would actually hit a variable that has no metadata (but is supposed to have), we still have the error in the expression log so this shouldn't make it harder to diagnose any missing metadata errors. This patch should fix dynamic_cast and also adds a bunch of test coverage to that language feature. Fixes rdar://10813639 Reviewers: davide, labath Reviewed By: labath Subscribers: friss, labath, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65932 llvm-svn: 368511
* [lldb][NFC] Remove unused IRForTarget::BuildRelocationRaphael Isemann2019-08-091-22/+0
| | | | llvm-svn: 368442
* [lldb][NFC] Unify InstrList typedef in IRForTargetRaphael Isemann2019-08-091-6/+2
| | | | llvm-svn: 368425
* [lldb] Refactor guard variable checks in IRForTargetRaphael Isemann2019-08-091-12/+12
| | | | | | | | Not NFC as this will probably fix a wrong guard variable check on Windows. Not sure though what Windows test can now be safely enabled. llvm-svn: 368417
* [lldb][NFC] Clean up logging in IRForTargetRaphael Isemann2019-08-091-167/+100
| | | | llvm-svn: 368415
* [lldb][NFC] Remove last C string uses from IRForTargetRaphael Isemann2019-08-091-10/+8
| | | | llvm-svn: 368406
* [lldb][NFC] Use range-based for-loops in IRForTargetRaphael Isemann2019-08-091-108/+40
| | | | llvm-svn: 368405
* [lldb][NFC] Modernize IRForTarget::CreateResultVariableRaphael Isemann2019-08-081-21/+20
| | | | llvm-svn: 368359
* [lldb][NFC] Move to StringRef in some places in IRForTargetRaphael Isemann2019-08-081-37/+32
| | | | llvm-svn: 368353
* [lldb][NFC] Directly use StringRef instead of temporary std::stringRaphael Isemann2019-08-081-13/+12
| | | | llvm-svn: 368346
* [lldb][NFC] Simplify return in MaybeHandleVariableRaphael Isemann2019-08-081-9/+4
| | | | | | This function anyway returns true, no need to do this extra work. llvm-svn: 368309
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-93/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-6/+12
| | | | | | | | | | 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-27/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [opaque pointer types] Update calls to CreateCall to pass the functionJames Y Knight2019-02-081-7/+9
| | | | | | type in lldb and polly. llvm-svn: 353549
* 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
* Simplify code by using Optional::getValueOr()Adrian Prantl2019-01-151-3/+1
| | | | llvm-svn: 351264
* Replace auto -> llvm::Optional<uint64_t>Adrian Prantl2019-01-151-2/+2
| | | | | | This addresses post-commit feedback for https://reviews.llvm.org/D56688 llvm-svn: 351237
* Make CompilerType::getBitSize() / getByteSize() return an optional result. NFCAdrian Prantl2019-01-151-6/+13
| | | | | | | | | | | | | | | | | | | | | | | The code in LLDB assumes that CompilerType and friends use the size 0 as a sentinel value to signal an error. This works for C++, where no zero-sized type exists, but in many other programming languages (including I believe C) types of size zero are possible and even common. This is a particular pain point in swift-lldb, where extra code exists to double-check that a type is *really* of size zero and not an error at various locations. To remedy this situation, this patch starts by converting CompilerType::getBitSize() and getByteSize() to return an optional result. To avoid wasting space, I hand-rolled my own optional data type assuming that no type is larger than what fits into 63 bits. Follow-up patches would make similar changes to the ValueObject hierarchy. rdar://problem/47178964 Differential Revision: https://reviews.llvm.org/D56688 llvm-svn: 351214
* Simplify Boolean expressionsJonas Devlieghere2018-12-151-16/+7
| | | | | | | | | | | This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
* 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
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-35/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Rename Error -> Status.Zachary Turner2017-05-121-1/+1
| | | | | | | | | | | | | | | 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
* Update for LLVM API removal of Function::getArgumentList()Reid Kleckner2017-03-161-5/+5
| | | | llvm-svn: 298011
* 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-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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
* Add a more succinct logging syntaxPavel Labath2017-01-181-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | This adds the LLDB_LOG macro, which enables one to write more succinct log statements. if (log) log->Printf("log something: %d", var); becomes LLDB_LOG(log, "log something: {0}, var); The macro still internally does the "if(log)" dance, so the arguments are only evaluated if logging is enabled, meaning it has the same overhead as the previous syntax. Additionally, the log statements will be automatically prefixed with the file and function generating the log (if the corresponding new argument to the "log enable" command is enabled), so one does not need to manually specify this in the log statement. It also uses the new llvm formatv syntax, which means we don't have to worry about PRIx64 macros and similar, and we can log complex object (llvm::StringRef, lldb_private::Error, ...) more easily. Differential Revision: https://reviews.llvm.org/D27459 llvm-svn: 292360
* Fix a couple of incorrect format string warningsLuke Drummond2016-12-221-2/+2
| | | | | | | | | | | This patch fixes use of incorrect `%zi` to format a plain `int`, and using `%llu` to format a `uint64_t`. The fix is to use the new typesafe `llvm::Formatv` based API. Differential Revision: https://reviews.llvm.org/D28028 Subscribers: lldb-commits llvm-svn: 290359
* Handle empty strings when looking for a CFString's encoding.Sean Callanan2016-12-011-1/+1
| | | | | | Should fix the bots. llvm-svn: 288403
* Handle UTF-16 and UTF-32 constant CFStringsSean Callanan2016-12-011-53/+63
| | | | | | | | | | | | | | | We have a longstanding issue where the expression parser does not handle wide CFStrings (e.g., @"凸凹") correctly, producing the useless error message Internal error [IRForTarget]: An Objective-C constant string's string initializer is not an array error: warning: expression result unused error: The expression could not be prepared to run in the target This is just a side effect of the fact that we don't handle wide string constants when converting these to CFStringCreateWithBytes. That function takes the string's encoding as an argument, so I made it work and added a testcase. https://reviews.llvm.org/D27291 <rdar://problem/13190557> llvm-svn: 288386
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-021-1/+1
| | | | | | | | | | Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
* Fixed TestObjCStructArgument/i386; expressions can now call ObjC class methods.Sean Callanan2016-09-291-1/+177
| | | | | | <rdar://problem/28502241> llvm-svn: 282657
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-1606/+1537
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* The error stream in IRForTarget is never null, so use it instead of the log.Sean Callanan2016-08-271-96/+48
| | | | llvm-svn: 279894
* Don't crash when trying to capture persistent variables in a block.Sean Callanan2016-08-261-5/+26
| | | | | | | | | Reports an error instead. We can fix this later to make persistent variables work, but right now we hit an LLVM assertion if we get this wrong. <rdar://problem/27770298> llvm-svn: 279850
* 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
OpenPOWER on IntegriCloud