| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 247766
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 212411
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
when other cases get added.
llvm-svn: 204751
|
| |
|
|
|
|
| |
that call debug-information intrinsics.
llvm-svn: 204750
|
| |
|
|
|
|
| |
<rdar://problem/15188389>
llvm-svn: 192489
|
| |
|
|
|
|
|
|
| |
constants before using them in the IR interpreter.
Patch by Félix Cloutier.
llvm-svn: 190877
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
reading non-standard value sizes.
<rdar://problem/14081292>
llvm-svn: 183448
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Implemented the SExt instruction, and
- eliminated redundant codepaths for constant
handling.
Added test cases.
<rdar://problem/13244258>
<rdar://problem/13955820>
llvm-svn: 183344
|
| |
|
|
| |
llvm-svn: 183140
|
| |
|
|
|
|
| |
<rdar://problem/14005311>
llvm-svn: 183022
|
| |
|
|
|
|
|
|
| |
Scalar now can make itself signed if needed.
<rdar://problem/13977632>
llvm-svn: 182668
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
can't handle the size. This came from trying to do:
(lldb) p typedef float __attribute__((ext_vector_type(8))) __ext_vector_float8; (__ext_vector_float8)$ymm0
llvm-svn: 180235
|
| |
|
|
| |
llvm-svn: 179918
|
| |
|
|
|
|
|
| |
now that the IR interpreter and the JIT share the same
materialization codepaths.
llvm-svn: 179842
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++.
Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.
llvm-svn: 179779
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
it doesn't actually hold any important state.
llvm-svn: 179702
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
It doesn't use it yet; the next step is to make it
use the IRMemoryMap instead of its own conjured-up
Memory class.
llvm-svn: 179650
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
interpreter. They now have correct values, even
when the process is not running.
llvm-svn: 177372
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
| |
<rdar://problem/13168967>
llvm-svn: 174579
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
<rdar://problem/12978619>
llvm-svn: 172013
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
the IR interpreter.
<rdar://problem/12921700>
llvm-svn: 170934
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"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
|
| |
|
|
|
|
|
|
| |
interpreter.
<rdar://problem/12657742>
llvm-svn: 169063
|
| |
|
|
|
|
|
|
| |
- use macros from inttypes.h for format strings instead of OS-specific types
Patch from Matt Kopec!
llvm-svn: 168945
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
change in the LLDB target data API.
llvm-svn: 165754
|
| |
|
|
|
|
| |
per address space pointer sizes to be optimized correctly.
llvm-svn: 165726
|
| |
|
|
| |
llvm-svn: 165396
|
| |
|
|
|
|
| |
return bool.
llvm-svn: 161719
|
| |
|
|
|
|
|
|
|
| |
and instead made us use implicit casts to bool.
This generated a warning in C++11.
<rdar://problem/11930775>
llvm-svn: 161559
|
| |
|
|
| |
llvm-svn: 160338
|
| |
|
|
|
|
| |
interpreter.
llvm-svn: 155360
|
| |
|
|
|
|
|
| |
Prepare LLDB to be built with C++11 by hiding all accesses to std::tr1 behind
macros that allows us to easily compile for either C++.
llvm-svn: 152698
|
| |
|
|
|
|
| |
with non-constant indexes.
llvm-svn: 151734
|
| |
|
|
|
|
|
|
|
| |
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
|