summaryrefslogtreecommitdiffstats
path: root/lldb/source/Expression/IRMemoryMap.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Fix ARM32 inferior callsJan Kratochvil2019-12-211-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-30/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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
* [IRMemoryMap] Fix -Wimplicit-fallthrough in -DLLVM_ENABLE_ASSERTIONS=off buildFangrui Song2019-04-121-1/+1
| | | | llvm-svn: 358249
* 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
* [IRMemoryMap] Shrink Allocation and make it move-only (NFC)Vedant Kumar2018-08-081-5/+6
| | | | | | | | | | | | | | | | | Profiling data show that Allocation::operator= is hot (see the data attached to the Phab review). Reorder a few fields within Allocation to avoid implicit structure padding and shrink the structure. This should make copies a bit cheaper. Also, given that an Allocation contains a std::vector (by way of DataBufferHeap), it's preferable to make it move-only instead of permitting expensive copies. As an added benefit this allows us to have a single Allocation constructor instead of two. Differential Revision: https://reviews.llvm.org/D50271 llvm-svn: 339290
* 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
* [IRMemoryMap] Avoid redundant zero-init in the Allocation constructor (NFC)Vedant Kumar2018-08-061-5/+1
| | | | | | | In the lldb-bench/arithmetic benchmark, 1.7% of the total running time is spent zero-initializing a std::vector that has already been zeroed. llvm-svn: 339051
* [IRMemoryMap] Fix the alignment adjustment in MallocVedant Kumar2018-05-311-6/+12
| | | | | | | | | | | | | | | | | | | | This prevents Malloc from allocating the same chunk of memory twice, as a byproduct of an alignment adjustment which gave the client access to unallocated memory. Prior to this patch, the newly-added test failed with: $ lldb-test ir-memory-map ... ir-memory-map-overlap1.test ... Command: malloc(size=64, alignment=32) Malloc: address = 0x1000cd080 Command: malloc(size=64, alignment=8) Malloc: address = 0x1000cd0b0 Malloc error: overlapping allocation detected, previous allocation at [0x1000cd080, 0x1000cd0c0) Differential Revision: https://reviews.llvm.org/D47551 llvm-svn: 333697
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-18/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-15/+16
| | | | | | | | | | | | | | | 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-2/+2
| | | | 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
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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
* Silence some -Wstring-conversion warningsPavel Labath2017-01-051-1/+1
| | | | | | | | lldbassert(!"foo") -> lldbassert(0 && "foo") In one case, this actually detected a logic error in the assertion (missing !). llvm-svn: 291102
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-751/+681
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Fixed a problem in IRMemoryMap where the flag to zero out memory was ignored.Sean Callanan2016-06-091-0/+7
| | | | llvm-svn: 272320
* Updated the FindSpace() algorithm to avoid the 0 page when it's unsafe.Sean Callanan2016-06-091-8/+109
| | | | | | | | | | | | | | | | | | | | | | | Previously we eliminated the randomized scheme for finding memory when the underlying process cannot allocate memory, and replaced it with an algorithm that starts the allocations at 00x. This was more determinstic, but runs into problems on embedded targets where the pages near 0x0 are in fact interesting memory. To deal with those cases, this patch does two things: - It makes the default fallback be an address that is less likely than 0x0 to contain interesting information. - Before falling back to this, it adds an algorithm that consults the GetMemoryRegionInfo() API to see if it can find an unmapped area. This should eliminate the randomness (and unpredictable memory accesseas) of the previous scheme while making expressions more likely to return correct results. <rdar://problem/25545573> llvm-svn: 272301
* 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
* Update for llvm change. NFC.Rafael Espindola2016-01-181-1/+1
| | | | llvm-svn: 258080
* Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. ↵Jim Ingham2015-11-041-5/+16
| | | | | | | | Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
* Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a ↵Ewan Crawford2015-07-141-0/+26
| | | | | | | | | | | | | | | | | | | | 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
* Dont' use a random probe & alloc strategy for the IRMemoryMap.Zachary Turner2014-07-091-30/+8
| | | | | | | | | | | | | | | | | | | | | | | The current strategy for host allocation is to choose a random address and attempt to allocate there, eventually failing if the allocation cannot be satisfied. The C standard only guarantees that RAND_MAX >= 32767, so for platforms that use a very small RAND_MAX allocations will fail with very high probability. On such platforms (Windows is one), you can reproduce this trivially by running lldb, typing "expr (3)" and then hitting enter you see a failure. Failures generally happen with a frequency of about 1 failure every 5 evaluations. There is no good reason that allocations need to look like "real" pointers, so this patch changes the allocation scheme to simply jump straight to the end and grab a free chunk of memory. Reviewed By: Sean Callanan Differential Revision: http://reviews.llvm.org/D4300 llvm-svn: 212630
* remove trailing whitespace + remove some useless commentsSylvestre Ledru2014-07-061-89/+87
| | | | llvm-svn: 212411
* Add lldb-gdbserver support for Linux x86_64.Todd Fiala2014-06-301-1/+6
| | | | | | | | | | | | | | | | | | | | | This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
* Fix silly compilation error.Zachary Turner2014-06-251-2/+2
| | | | llvm-svn: 211728
* Fix a bug in the IRMemoryMap which generated bogus allocations.Zachary Turner2014-06-251-16/+31
| | | | | | | | | | | | | Previously, only the starting locations of the candidate interval and the existing interval were compared. To correctly detect range intersections, it is necessary to compare the entire range of both intervals against each other. Reviewed by: scallanan Differential Revision: http://reviews.llvm.org/D4286 llvm-svn: 211726
* JITed functions can now have debug info and be debugged with debug and ↵Greg Clayton2014-03-241-1/+1
| | | | | | | | | | | | | | | | | | | source info: (lldb) b puts (lldb) expr -g -i0 -- (int)puts("hello") First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression. Main features: - New ObjectFileJIT class that can be easily created for JIT functions - debug info can now be enabled when parsing expressions - source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit - "expr -g --" allows you to single step through your expression function with source code <rdar://problem/16382881> llvm-svn: 204682
* Hardened against reads in the IRMemoryMap thatSean Callanan2014-03-041-0/+14
| | | | | | | | exceed the bounds of the backing memory. <rdar://problem/16088322> llvm-svn: 202899
* MingW compilation (windows). Includes various refactoring to improve ↵Virgile Bello2013-08-231-3/+3
| | | | | | portability. llvm-svn: 189107
* Initialize m_leak member variable.Michael Sartain2013-08-061-8/+8
| | | | llvm-svn: 187822
* Remove the process's reservation cache and don'tSean Callanan2013-06-271-24/+2
| | | | | | | | | | | | | | | | | | | | | | bother checking if a region is safe to use. In cases where regions need to be synthesized rather than properly allocated, the memory reads required to determine whether the area is used are - insufficient, because intermediate locations could be in use, and - unsafe, because on some platforms reading from memory can trigger events. All this only makes a difference on platforms where memory allocation in the target is impossible. Behavior on platforms where it is possible should stay the same. <rdar://problem/14023970> llvm-svn: 185046
* Fixed a problem in the expression parser thatSean Callanan2013-06-171-4/+4
| | | | | | | | | caused the IR interpreter not to work if the process had finished running. <rdar://problem/14124301> llvm-svn: 184125
* Fixed printf build warning.Greg Clayton2013-06-041-1/+1
| | | | llvm-svn: 183250
* Fix various build warnings.Matt Kopec2013-06-031-6/+6
| | | | llvm-svn: 183140
* Fixed a bug where persistent variables did notSean Callanan2013-05-221-1/+23
| | | | | | | | | | | | | | | | | live as long as they needed to. This led to equality tests involving persistent variables often failing or succeeding when they had no business doing so. To do this, I introduced the ability for a memory allocation to "leak" - that is, to persist in the process beyond the lifetime of the expression. Hand-declared persistent variables do this now. <rdar://problem/13956311> llvm-svn: 182528
* Added a per-process cache for reserved memorySean Callanan2013-05-161-15/+28
| | | | | | | | | | | | | | | | regions that aren't actually allocated in the process. This cache is used by the expression parser if the underlying process doesn't support memory allocation, to avoid needless repeated searches for unused address ranges. Also fixed a silly bug in IRMemoryMap where it would continue searching even after it found a valid region. <rdar://problem/13866629> llvm-svn: 182028
* Fixed a few obvious errors pointed out by the static analyzer.Jim Ingham2013-05-151-1/+1
| | | | llvm-svn: 181911
* Performance optimizations to ClangUserExpression,Sean Callanan2013-04-271-5/+26
| | | | | | | | | | | | | | | | | | | | 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
* Change Malloc to request an aligned memory size.Matt Kopec2013-04-261-4/+10
| | | | | | This fixes a problem on Linux where allocated memory would get overun in some use cases (ie. in TestExprs2.py). llvm-svn: 180614
* Simplified the management of the data buffer forSean Callanan2013-04-191-35/+50
| | | | | | | | an Allocation to reduce heap fragmentation and make the code less brittle (and to make some buildbots happier). llvm-svn: 179868
* Reverted 179810, which breaks the expressionSean Callanan2013-04-191-3/+1
| | | | | | parser. llvm-svn: 179832
* Made IRMemoryMap::FindSpace a little cleverer,Sean Callanan2013-04-191-40/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and made attempts to allocate memory in the process fall back to FindSpace and just allocate memory on the host (but with real-looking pointers, hence FindSpace) if the process doesn't allow allocation. This allows expressions to run on processes that don't support allocation, like core files. This introduces an extremely rare potential problem: If all of the following are true: - The Process doesn't support allocation; - the user writes an expression that refers to an address that does not yet map to anything, or is dynamically generated (e.g., the result of calling a function); and - the randomly-selected address for the static data for that specific expression runs into the address the user was expecting to work with; then dereferencing the pointer later results in the user seeing something unexpected. This is unlikely but possible; as a future piece of work, we should have processes be able to hint to the expression parser where it can allocate temporary data of this kind. llvm-svn: 179827
* Try and unblock issue found in: ↵Greg Clayton2013-04-181-1/+3
| | | | | | http://lab.llvm.org:8011/builders/lldb-x86_64-linux/builds/3564 llvm-svn: 179810
* This commit changes the way LLDB executes userSean Callanan2013-04-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expressions. Previously, ClangUserExpression assumed that if there was a constant result for an expression then it could be determined during parsing. In particular, the IRInterpreter ran while parser state (in particular, ClangExpressionDeclMap) was present. This approach is flawed, because the IRInterpreter actually is capable of using external variables, and hence the result might be different each run. Until now, we papered over this flaw by re-parsing the expression each time we ran it. I have rewritten the IRInterpreter to be completely independent of the ClangExpressionDeclMap. Instead of special-casing external variable lookup, which ties the IRInterpreter closely to LLDB, we now interpret the exact same IR that the JIT would see. This IR assumes that materialization has occurred; hence the recent implementation of the Materializer, which does not require parser state (in the form of ClangExpressionDeclMap) to be present. Materialization, interpretation, and dematerialization are now all independent of parsing. This means that in theory we can parse expressions once and run them many times. I have three outstanding tasks before shutting this down: - First, I will ensure that all of this works with core files. Core files have a Process but do not allow allocating memory, which currently confuses materialization. - Second, I will make expression breakpoint conditions remember their ClangUserExpression and re-use it. - Third, I will tear out all the redundant code (for example, materialization logic in ClangExpressionDeclMap) that is no longer used. While implementing this fix, I also found a bug in IRForTarget's handling of floating-point constants. This should be fixed. llvm-svn: 179801
* Try to unbreak the lldb-x86_64-linux buildbot after recent ↵Greg Clayton2013-04-181-15/+15
| | | | | | std::auto_ptr/std::unique_ptr changes. llvm-svn: 179799
* Updated the IRInterpreter to work with anSean Callanan2013-04-171-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IRMemoryMap rather than through its own memory abstraction. This considerably simplifies the code, and makes it possible to run the IRInterpreter multiple times on an already-parsed expression in the absence of a ClangExpressionDeclMap. Changes include: - ClangExpressionDeclMap's interface methods for the IRInterpreter now take IRMemoryMap arguments. They are not long for this world, however, since the IRInterpreter will soon be working with materialized variables. - As mentioned above, removed the Memory class from the IR interpreter altogether. It had a few functions that remain useful, such as keeping track of Values that have been placed in memory, so I moved those into methods on InterpreterStackFrame. - Changed IRInterpreter to work with lldb::addr_t rather than Memory::Region as its primary currency. - Fixed a bug in the IRMemoryMap where it did not report correct address byte size and byte order if no process was present, because it was using Target::GetDefaultArchitecture() rather than Target::GetArchitecture(). - Made IRMemoryMap methods clear the Errors they receive before running. Having to do this by hand is just annoying. The testsuite seems happy with these changes, but please let me know if you see problems (especially in use cases without a process). llvm-svn: 179675
* Flipped the big switch: LLDB now uses the new Sean Callanan2013-04-161-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | Materializer for all expressions that need to run in the target. This includes the following changes: - Removed a bunch of (de-)materialization code from ClangExpressionDeclMap and assumed the presence of a Materializer where we previously had a fallback. - Ensured that an IRMemoryMap is passed into ClangExpressionDeclMap::Materialize(). - Fixed object ownership on LLVMContext; it is now owned by the IRExecutionUnit, since the Module and the ExecutionEngine both depend on its existence. - Fixed a few bugs in IRMemoryMap and the Materializer that showed up during testing. llvm-svn: 179649
* Added logging to each entity in the MaterializerSean Callanan2013-04-151-1/+14
| | | | | | to make debugging easier when things go wrong. llvm-svn: 179576
* Fixed a few bugs in IRMemoryMap:Sean Callanan2013-04-151-3/+47
| | | | | | | | | | | | | | - If an allocation is mirrored between the host and the process, update the host's version before returning a DataExtractor pointing to it. - If anyone attempts to access memory in a process/target that does not have a corresponding allocation, try accessing the memory directly before erroring out. llvm-svn: 179561
OpenPOWER on IntegriCloud