[lldb-dev] lldb -- architecture level question -- linux v. darwin

[Jason E. Aten]

On Wed, Mar 16, 2011 at 2:59 PM, Jim Ingham <jingham at apple.com> wrote:

> To make this be an "all lldb" solution, some parts of the way that lldb
> does expression evaluation would have to be enhanced.  Right now, for
> instance, we compile, JIT and evaluate expressions, and then clean up after
> ourselves completely.  We don't insert code and, for instance, put it in a
> nice bundle with symbols et al and tell the linker about it so anybody else
> could reuse it.  We just inject a raw blob of code, set the pc somewhere and
> go.  So even if we didn't clean up the injected code once the execution is
> complete, there isn't any way to reuse the functionality you've compiled up.
>  Actually this is a bit of a lie, there are a couple of fairly special
> purpose mechanisms to do this (ClangFunction, and ClangUtilityFunction) but
> you have to be inside lldb to use them...
>
> Sorry,  I'm confused here; please clarify if you can.  In chapters 3 and 4
of the Kaleidoscope LLVM tutorial, we define and JIT-compile functions on
the fly that are then reusable many, many times, in subsequently defined
functions.  I am certain supposing that I have to provide a parser, generate
ASTs, and call the LLVM functions like Kaleidoscope does in chapter 4, but
how the code in that case preserved?  Is this a different mechanism or the
same mechanism that the Expression classes use, as described in
http://lldb.llvm.org/architecture.html<http://www.google.com/url?q=http%3A%2F%2Flldb.llvm.org%2Farchitecture.html&sa=D&sntz=1&usg=AFrqEzdAeBIJLtwe3ZjgO4EUnnAc1JANzQ>
 :

 Once expressions have be compiled into an AST, we can then traverse this
> AST and either generate a DWARF expression that contains simple opcodes that
> can be quickly re-evaluated each time an expression needs to be evaluated,
> or JIT'ed up* into code that can be run on the process being debugged*.




> We also don't generate debug information, 'cause in this context it
> wouldn't make sense to.  And there isn't a way to say "evaluate this
> expression in language X" if X is not C/C++/ObjC…
>
> I agree 100% that debug info would be totally necessary. In fact it would
probably become necessary to extend dwarf to preserve the full text of the
source, so that the source line numbers can be referred to.  (or is there
some already preexisting mechanism to do this?)

The AOT compiler that I want to use is for the D programming language (
http://www.digitalmars.com/d/), and already uses LLVM to generate ELF code
and DWARF information on Linux (
https://bitbucket.org/prokhin_alexey/ldc2/wiki/Home is the home of the
compiler, which is not bug free but very complete).



> We certainly want to come up with a clean way to reuse functions defined in
> "expressions" from lldb, though that's not at the front of our queue.
>  Making them debuggable would also be important: once you allow this sort of
> thing it's bound to grow in complexity to the point where you'll need to be
> able to debug it.  And we would be happy to support other languages, though
> at present we're tied to Clang as our expression front end…
>
>
Right. I would have to provide the expression parsing and so forth, but that
is already completed.  Perhaps a minimal hook from LLDB into (what's the
right interface? I haven't read through the Expression code yet) that tells
the inferior process to CompileString("sort(preexistingCollection,
function(a,b) { a< b}"); effectively doing the compilation.  Or the JIT
could be done by customizing the LLDB side.  It just isn't clear to me on
what side of the debugger - debuggee interface the JIT needs to run on most
effectively.  Or does it matter?



> Another way to do this would be to build a little code injection rig and
> insert it into the debuggee - for instance by having a dylib that does this
> job and calling "dlopen" from the debugger to insert it.  Then when you
> wanted to insert some new code, you would put it in a file, and call some
> "MyRigInsertCode" type routine in your dylib.  Then that would make a little
> bundle, stuff it into the target, tell the loader about it (which would tell
> the debugger about it) and then those new functions would be available in
> further expressions you write from the debugger.


Yes, that's it!  I think we're thinking along exactly the same lines.  Since
ideally I want to include llvm based JIT-compiler functionality in some sort
of library for D, (in order to be able to compile at runtime), this could be
the right path.  Get two birds with one stone.

Comments welcome.

Thanks guys.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20110316/2e715293/attachment.html>