There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime.
Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use.
llvm-svn: 228892
This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for)
The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee)
This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help
No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet
llvm-svn: 227274
MS ABI guard variables end with @4IA, so this patch teaches the
interpreter about that. Additionally, there was an issue with
TurnGuardLoadIntoZero which was causing some guard uses of a
variable to be missed. This fixes that by calling
Instruction::replaceAllUsesWith() instead of trying to replicate
that function.
llvm-svn: 225547
off_t is a type which is used for file offsets. Even more
specifically, it is only used by a limited number of C APIs that
deal with files. Any usage of off_t where the variable is not
intended to be used with one of these APIs is a bug, by definition.
This patch corrects some easy mis-uses of off_t, generally by
converting them to lldb::offset_t, but sometimes by using other
types such as size_t, when appropriate.
The use of off_t to represent these offsets has worked fine in
practice on linux-y platforms, since we used _FILE_OFFSET_64 to
guarantee that off_t was a uint64. On Windows, however,
_FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit.
So the usage of off_t on Windows actually leads to legitimate bugs.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4358
llvm-svn: 212192
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
(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
This is a mechanical cleanup of unused functions. In the case where the
functions are referenced (in comment form), I've simply commented out the
functions. A second pass to clean that up is warranted.
The functions which are otherwise unused have been removed. Some of these were
introduced in the initial commit and not in use prior to that point!
NFC
llvm-svn: 204310
What was use_iterator is now user_iterator. Also switch to range-based
APIs, as in Clang r203365.
(This part of the change was missed in r203463)
Differential Revision: http://llvm-reviews.chandlerc.com/D3030
llvm-svn: 203475
specify a pointer size until code gen. So we just
make all our pointer-sized integer literals 64-bit.
That doesn't seem to hurt anything.
llvm-svn: 197774
In almost all cases, the misuse is about "%lu" being used instead of the correct "%zu" (even though these are compatible on 64-bit platforms in practice). There are even a couple of cases where "%ld" (ie., signed int) is used instead of "%zu", and one where "%lu" is used instead of "%" PRIu64.
Fixes bug #17551.
Patch by "/dev/humancontroller"
llvm-svn: 193832
If we are replacing a function with the nobuiltin attribute, it may be called
with the builtin attribute on call sites. Remove any such attributes since it's
illegal to have a builtin call to something other than a nobuiltin function.
This fixes the current buildbot breakage (where LLDB crashes on
"expression new foo(42)").
llvm-svn: 186990
delete a constant after we replaced it with a
dynamically-computed value. Also ensured that we
replace all users of the constant if there are
multiple ones. Added a testcase.
<rdar://problem/14379043>
llvm-svn: 186363
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
llvm-svn: 186130
been suitable for preparing a single IR function
for operation in the target. However, using blocks
and lambdas creates other IR functions that also
need to be processed.
I have audited IRForTarget to make it process
multiple functions. Where IRForTarget would add
new instructions at the beginning of the main
expression function, it now adds them on-demand
in the function where they are needed. This is
enabled by a system of FunctionValueCaches, which
invoke a lambda to create or derive the values as
needed, or report the result of that lambda if it
has already been called for the given function.
<rdar://problem/14180236>
llvm-svn: 185224
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
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
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
and the JITted code are managed by a standalone
class that handles memory management itself.
I have removed RecordingMemoryManager and
ProcessDataAllocator, which filled similar roles
and had confusing ownership, with a common class
called IRExecutionUnit. The IRExecutionUnit
manages all allocations ever made for an expression
and frees them when it goes away. It also contains
the code generator and can vend the Module for an
expression to other clases.
The end goal here is to make the output of the
expression parser re-usable; that is, to avoid
re-parsing when re-parsing isn't necessary.
I've also cleaned up some code and used weak pointers
in more places. Please let me know if you see any
leaks; I checked myself as well but I might have
missed a case.
llvm-svn: 177364
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
Ilia K