Commit Graph

120 Commits

Author SHA1 Message Date
Saleem Abdulrasool 324a103619 sweep up -Wformat warnings from gcc
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
2014-04-04 04:06:10 +00:00
Greg Clayton 23f8c95a44 JITed functions can now have debug info and be debugged with debug and source info:
(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
2014-03-24 23:10:19 +00:00
Sean Callanan 7c435a5ede Lock the JIT before using it.
<rdar://problem/15958296>

llvm-svn: 200951
2014-02-06 22:25:20 +00:00
Sean Callanan 4f2c198617 Better logging for the IRExecutionUnit so that
we can see exactly what data was put where.

llvm-svn: 199701
2014-01-21 00:54:48 +00:00
Filip Pizlo bfcff68516 Fix build after LLVM memory management API changes.
llvm-svn: 191806
2013-10-02 01:43:46 +00:00
Michael Sartain 89c862f298 clean up about 22 warnings messages
llvm-svn: 187900
2013-08-07 19:05:15 +00:00
Jim Ingham 56d404281f The DisassemblerLLVMC has a retain cycle - the InstructionLLVMC's contained in its instruction
list have a shared pointer back to their DisassemblerLLVMC.  This checkin force clears the InstructionList
in all the places we use the DisassemblerSP to stop the leaking for now.  I'll go back and fix this
for real when I have time to do so.

<rdar://problem/14581918>

llvm-svn: 187473
2013-07-31 02:19:15 +00:00
Sean Callanan ffae944a39 Fixed IRExecutionUnit so that it looks up addresses
correctly.  We have been getting lucky since most
expressions generate only one section (or the first
code section contains all the code), but sometimes
it actually matters.

<rdar://problem/14180236>

llvm-svn: 185054
2013-06-27 01:42:47 +00:00
Sean Callanan 1aee70b773 Fixed IRExecutionUnit build failures due to changes
in the underlying llvm::JITMemoryManager API.

llvm-svn: 181387
2013-05-08 01:30:52 +00:00
Greg Clayton 7b0992d9cd After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.
llvm-svn: 179805
2013-04-18 22:45:39 +00:00
Greg Clayton e01e07b6e7 Since we use C++11, we should switch over to using std::unique_ptr when 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
2013-04-18 18:10:51 +00:00
Sean Callanan 14b1bae5ee Flipped the big switch: LLDB now uses the new
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
2013-04-16 23:25:35 +00:00
Sean Callanan b024d87822 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.

llvm-svn: 179539
2013-04-15 17:12:47 +00:00
Sean Callanan ec1c0b3faa Fixed the way we allocate executable memory on
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
2013-04-09 01:13:08 +00:00
Sean Callanan 5a1af4e63a 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.

llvm-svn: 178832
2013-04-05 02:22:57 +00:00
Greg Clayton 3faf47c462 <rdar://problem/11730263>
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
2013-03-28 23:42:53 +00:00
Greg Clayton 5160ce5c72 <rdar://problem/13521159>
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
2013-03-27 23:08:40 +00:00
Sean Callanan 44bc657efe Fixed a problem where inline assembly errors caused
LLDB to crash.

<rdar://problem/13497915>

llvm-svn: 178115
2013-03-27 03:09:55 +00:00
Sean Callanan 2c04735630 Updated the IRExecutionUnit to keep local copies
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
2013-03-19 23:03:21 +00:00
Sean Callanan 8dfb68e039 Refactored the expression parser so that the IR
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
2013-03-19 00:10:07 +00:00