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
- Implemented the SExt instruction, and
- eliminated redundant codepaths for constant
handling.
Added test cases.
<rdar://problem/13244258>
<rdar://problem/13955820>
llvm-svn: 183344
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
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
interpreter. They are a legacy from when the IR
interpreter didn't work with materialized values
but rather got values directly from
ClangExpressionDeclMap.
Also updated the #includes for IRInterpreter
accordingly.
llvm-svn: 180565
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
will be gone soon!) that lets it interpret a function
using just an llvm::Module, an llvm::Function, and a
MemoryMap.
Also added an API to IRExecutionUnit to get at its
llvm::Function, so that the IRInterpreter can work
with it.
llvm-svn: 179704
a ClangExpressionDeclMap. Any functions that
require value resolution etc. fail if the
ClangExpressionDeclMap isn't present - which is
exactly what is desired.
llvm-svn: 179695
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
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
- removed an unnecessary variable
- fixed an issue where we sometimes
wrote too much data into a buffer
- made the recognition of variables
as "this" a little more conservative
<rdar://problem/13216268>
llvm-svn: 175318
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
migration in r171366.
I don't know anything about lldb, but a force run of the build bot indicated it
would need this patch. I'll try to watch the build bot to get it green.
llvm-svn: 171374
"self" when those pointers are in registers.
Previously in this case the IRInterpreter would
handle them just as if the user had typed in
"$rdi", which isn't safe because $rdi is passed
in through the argument struct.
Now we correctly break out all three cases (i.e.,
normal variables in registers, $reg, and this/self),
and handle them in a way that's a little bit easier
to read and change.
This results in more accurate printing of "this" and
"self" pointers all around. I have strengthened the
optimized-code test case for Objective-C to ensure
that we catch regressions in this area reliably in
the future.
<rdar://problem/12693963>
llvm-svn: 169924
- remove unused members
- add NO_PEDANTIC to selected Makefiles
- fix return values (removed NULL as needed)
- disable warning about four-char-constants
- remove unneeded const from operator*() declaration
- add missing lambda function return types
- fix printf() with no format string
- change sizeof to use a type name instead of variable name
- fix Linux ProcessMonitor.cpp to be 32/64 bit friendly
- disable warnings emitted by swig-generated C++ code
Patch by Matt Kopec!
llvm-svn: 169645
The attached patch adds eValueTypeVector to lldb_private::Value. The nested struct Vector is patterned after RegisterValue::m_data.buffer. This change to Value allows ClangExpressionDeclMap::LookupDecl to return vector register data for consumption by InterpreterStackFrame::ResolveValue. Note that ResolveValue was tweaked slightly to allocate enough memory for vector registers.
An immediate result of this patch is that "expr $xmm0" generates the same results on Linux as on the Mac, which is good enough for TestRegisters.py. In addition, the log of m_memory.PrintData(data_region.m_base, data_region.m_extent) shows that the register content has been resolved successfully. On the other hand, the output is glaringly empty:
runCmd: expr $xmm0
output: (unsigned char __attribute__((ext_vector_type(16)))) $0 = {}
Expecting sub string: vector_type
Matched
llvm-svn: 167033
JIT when printing the values of registers (e.g.,
"expr $pc"). Now the expression parser can do this
in the IR interpreter without running code in the
inferior process.
llvm-svn: 150554
sufficiently general - it could only handle
literals and operations that didn't change the
data. Now the constant evaluator passes APInt
values around, and can handle GetElementPtr
constants.
llvm-svn: 150034
LLVM/Clang. This brings in several fixes, including:
- Improvements in the Just-In-Time compiler's
allocation of memory: the JIT now allocates
memory in chunks of sections, improving its
ability to generate relocations. I have
revamped the RecordingMemoryManager to reflect
these changes, as well as to get the memory
allocation and data copying out fo the
ClangExpressionParser code. Jim Grosbach wrote
the updates to the JIT on the LLVM side.
- A new ExternalASTSource interface to allow LLDB to
report accurate structure layout information to
Clang. Previously we could only report the sizes
of fields, not their offsets. This meant that if
data structures included field alignment
directives, we could not communicate the necessary
alignment to Clang and accesses to the data would
fail. Now we can (and I have update the relevant
test case). Thanks to Doug Gregor for implementing
the Clang side of this fix.
- The way Objective-C interfaces are completed by
Clang has been made consistent with RecordDecls;
with help from Doug Gregor and Greg Clayton I have
ensured that this still works.
- I have eliminated all local LLVM and Clang patches,
committing the ones that are still relevant to LLVM
and Clang as needed.
I have tested the changes extensively locally, but
please let me know if they cause any trouble for you.
llvm-svn: 149775
due to RTTI worries since llvm and clang don't use RTTI, but I was able to
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared
pointer from just a pointer, which is also easily solved using the
std::tr1::enable_shared_from_this class.
The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.
So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).
llvm-svn: 149207
an error along with its boolean result. The
expression parser reports this error if the
interpreter fails and the expression could not be
run in the target.
llvm-svn: 148870
Sean Callanan