| 4b1b8d9e3ae7d4b858e2c1f0ed719655496e6857 |
|
23-May-2013 |
Sean Callanan <scallanan@apple.com> |
GCC gets confused by enums in bitfields, so I
removed the bitfields. This should be conforming
C++11, though, cf. C++03 9.6(3):
"
A bit-field shall have integral or enumeration
type (3.9.1).
"
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182545 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| e7872343f18b90e4134fb91a616b138ba6bd6b92 |
|
23-May-2013 |
Sean Callanan <scallanan@apple.com> |
Fixed a bug where persistent variables did not
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>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182528 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| 06761aad61604feba2af78c873b104e0415d9361 |
|
19-Apr-2013 |
Sean Callanan <scallanan@apple.com> |
Simplified the management of the data buffer for
an Allocation to reduce heap fragmentation and
make the code less brittle (and to make some
buildbots happier).
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179868 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| 73cb33aa0c9a59cfd42c3cea222378dc9d15abb0 |
|
19-Apr-2013 |
Sean Callanan <scallanan@apple.com> |
Made IRMemoryMap::FindSpace a little cleverer,
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179827 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| 102b2c2681c9a830afe25bfea35557421905e42c |
|
19-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| da0e332abdc9dbd058d2d1a02233237df6bee894 |
|
19-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
Try to unbreak the lldb-x86_64-linux buildbot after recent std::auto_ptr/std::unique_ptr changes.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179799 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| 0b10ef61ea60e24fe7736cd98bd5fb45efe9c816 |
|
18-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
Missed some cases when switching over to using our STD_UNIQUE_PTR macros.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179796 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| 76f9879afa1508febd5538a63a3fad7f01c6c64f |
|
16-Apr-2013 |
Sean Callanan <scallanan@apple.com> |
Added logging to each entity in the Materializer
to make debugging easier when things go wrong.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179576 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| faafd193bf7dc065e5f6fb99e4c538cc452af7e4 |
|
15-Apr-2013 |
Sean Callanan <scallanan@apple.com> |
Audited the existing Materializer code to ensure
that it works in the absence of a process. Codepaths
in the Materializer now use the best execution context
scope available to them.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179539 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| e287e900488e20e07ef986ec0524b872fbeafa5d |
|
13-Apr-2013 |
Sean Callanan <scallanan@apple.com> |
Now that ValueObjects permit writing, made the
Materializer use that API when dematerializing
variables.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179443 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| 934d6160f5e62914c20f8e229c5e1ca4d9ead99f |
|
12-Apr-2013 |
Sean Callanan <scallanan@apple.com> |
Implemented materialization and dematerialization
for variables in the new Materializer. This is
much easier now that the ValueObject API is solid.
I still have to implement reading bytes into a
ValueObject, but committing what I have so far.
This code is not yet used, so there will be fixes
when I switch the expression parser over to use the
new Materializer.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179416 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| f4b59480e8d1056b1638141a6a627b252f657db0 |
|
12-Apr-2013 |
Sean Callanan <scallanan@apple.com> |
Replicated the materialization logic for persistent
variables in the Materializer. We don't use this
code yet, but will soon once the other materializers
are online.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179390 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|
| 9e6f6a6f394bb570c5f1f9a850ec0befe4a59fef |
|
05-Apr-2013 |
Sean Callanan <scallanan@apple.com> |
Factored out memory access into the target process
from IRExecutionUnit into a superclass called
IRMemoryMap. IRMemoryMap handles all reading and
writing, ensuring that areas are kept track of and
memory is properly cached (and deleted).
Also fixed several cases where we would simply leak
binary data in the target process over time. Now
the expression objects explicitly own their
IRExecutionUnit and delete it when they go away. This
is why I had to modify ClangUserExpression,
ClangUtilityFunction, and ClangFunction.
As a side effect of this, I am removing the JIT
mutex for an IRMemoryMap. If it turns out that we
need this mutex, I'll add it in then, but right now
it's just adding complexity.
This is part of a more general project to make
expressions fully reusable. The next step is to
make materialization and dematerialization use
the IRMemoryMap API rather than writing and
reading directly from the process's memory.
This will allow the IR interpreter to use the
same data, but in the host's memory, without having
to use a different set of pointers.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178832 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Expression/IRMemoryMap.h
|