| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
parser.
llvm-svn: 179832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/lldb-x86_64-linux/builds/3564
llvm-svn: 179810
|
|
|
|
|
|
| |
the macros and just use C++11.
llvm-svn: 179805
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
std::auto_ptr/std::unique_ptr changes.
llvm-svn: 179799
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
to make debugging easier when things go wrong.
llvm-svn: 179576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
| |
Also improved logging and error handling in a few
spots in the Materializer.
llvm-svn: 179557
|
|
|
|
|
|
|
|
| |
that it works in the absence of a process. Codepaths
in the Materializer now use the best execution context
scope available to them.
llvm-svn: 179539
|
|
|
|
|
|
| |
Materializer.
llvm-svn: 179445
|
|
|
|
|
|
|
| |
Materializer use that API when dematerializing
variables.
llvm-svn: 179443
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 179416
|
|
|
|
|
|
|
|
| |
variables in the Materializer. We don't use this
code yet, but will soon once the other materializers
are online.
llvm-svn: 179390
|
|
|
|
|
|
|
|
|
|
| |
to the Materializer. Materialization is still done by
the ClangExpressionDeclMap; this will be the next thing
to move.
Also fixed a layout bug that this uncovered.
llvm-svn: 179318
|
|
|
|
|
|
|
|
| |
parser.
<rdar://problem/13631469>
llvm-svn: 179304
|
|
|
|
|
|
|
|
|
| |
Example:
CMake Error at cmake/modules/LLVMProcessSources.cmake:89 (message):
Found unknown source file
/llvm-toolchain-3.3~svn179293.cmake/tools/lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
llvm-svn: 179295
|
|
|
|
|
|
|
|
| |
entities with the new Materializer so that it only
registers those entities that actually need to be
placed in the struct.
llvm-svn: 179253
|
|
|
|
|
|
|
|
|
|
| |
information about each variable that needs to
be materialized for an expression to work. The
next step is to migrate all materialization code
from ClangExpressionDeclMap to Materializer, and
to use it for variable materialization.
llvm-svn: 179245
|
|
|
|
|
|
|
|
| |
doesn't have a corresponding type.
<rdar://problem/13596142>
llvm-svn: 179130
|
|
|
|
|
|
|
|
|
| |
behalf of the JIT. We don't need it to be writable
since we are using special APIs to write into it.
<rdar://problem/13599185>
llvm-svn: 179077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 178832
|
|
|
|
|
|
| |
This should fix the build breakage caused by the api change in 178663.
llvm-svn: 178700
|
|
|
|
|
|
|
|
|
|
|
|
| |
Symbol table function names should support lookups like symbols with debug info.
To fix this I:
- Gutted the way FindFunctions is used, there used to be way too much smarts only in the DWARF plug-in
- Made it more efficient by chopping the name up once and using simpler queries so that SymbolFile and Symtab plug-ins don't need to do as much
- Filter the results at a higher level
- Make the lldb_private::Symtab able to chop up C++ mangled names and make as much sense out of them as possible and also be able to search by basename, fullname, method name, and selector name.
llvm-svn: 178608
|
|
|
|
|
|
|
|
|
|
|
| |
Note: although it is now possible to declare blocks
and call them inside the same expression, we do not
generate correct block descriptors so these blocks
cannot be passed to functions like dispatch_async.
<rdar://problem/12578656>
llvm-svn: 178509
|
|
|
|
|
|
|
|
| |
manipulating the diagnostics engine.
<rdar://problem/13508470>
llvm-svn: 178399
|
|
|
|
|
|
|
|
|
|
| |
PC relative loads are missing disassembly comments when disassembled in a live process.
This issue was because some sections, like __TEXT and __DATA in libobjc.A.dylib, were being moved when they were put into the dyld shared cache. This could also affect any other system that slides sections individually.
The solution is to keep track of wether the bytes we will disassemble are from an executable file (file address), or from a live process (load address). We now do the right thing based off of this input in all cases.
llvm-svn: 178315
|
|
|
|
| |
llvm-svn: 178204
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
LLDB to crash.
<rdar://problem/13497915>
llvm-svn: 178115
|
|
|
|
|
|
| |
all of the casts that were being used and cleans the code up a bit. Also added the ability to dump the metadata.
llvm-svn: 178113
|
|
|
|
|
|
|
|
|
| |
went wrong and we tried to get layout information
that wasn't there.
<rdar://problem/13490170>
llvm-svn: 177880
|
|
|
|
|
|
|
|
|
| |
class symbol in the same expression, handle all
of them instead of just the first one.
<rdar://problem/13440133>
llvm-svn: 177794
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang requires them to have complete types, but
we were previously only completing them if they
were of tag or Objective-C object types.
I have implemented a method on the ASTImporter
whose job is to complete a type. It handles not
only the cases mentioned above, but also array
and atomic types.
<rdar://problem/13446777>
llvm-svn: 177672
|
|
|
|
| |
llvm-svn: 177503
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the data it writes down into the process even
if the process doesn't exist. This will allow
the IR interpreter to access static data allocated
on the expression's behalf.
Also cleaned up object ownership in the
IRExecutionUnit so that allocations are created
into the allocations vector. This avoids needless
data copies.
<rdar://problem/13424594>
llvm-svn: 177456
|
|
|
|
|
|
|
| |
interpreter. They now have correct values, even
when the process is not running.
llvm-svn: 177372
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Many "byte size" members and variables were using a mixture of uint32_t and size_t. Switching over to using uint64_t everywhere.
llvm-svn: 177091
|
|
|
|
|
|
| |
when clang asked for them by name.
llvm-svn: 177085
|
|
|
|
|
|
|
|
|
|
| |
uninitialized memory, to getTrivialTypeSourceInfo,
which initializes its memory, when creating trivial
TypeSourceInfos.
<rdar://problem/13332253>
llvm-svn: 176899
|
|
|
|
| |
llvm-svn: 176879
|
|
|
|
|
|
| |
in clang r176726. Fix the build of lldb
llvm-svn: 176790
|