On Wed, Mar 16, 2011 at 2:59 PM, Jim Ingham <span dir="ltr"><<a href="mailto:jingham@apple.com">jingham@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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...<br>

<br></blockquote><div>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<span class="Apple-style-span" style="color: rgb(102, 102, 102); font-size: 13px; "> <a href="http://www.google.com/url?q=http%3A%2F%2Flldb.llvm.org%2Farchitecture.html&sa=D&sntz=1&usg=AFrqEzdAeBIJLtwe3ZjgO4EUnnAc1JANzQ" style="color: rgb(51, 102, 153) !important; ">http://lldb.llvm.org/architecture.html</a> :</span></div>
<div><span class="Apple-style-span" style="color: rgb(102, 102, 102); font-size: 13px; "><br></span></div><meta http-equiv="content-type" content="text/html; charset=utf-8"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<span class="Apple-style-span" style="color: rgb(102, 102, 102); font-size: 13px; "> 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<i><b> into code that can be run on the process being debugged</b></i>.</span></blockquote>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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…<br>
<br></blockquote><div>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?)</div>
<div><br></div><div>The AOT compiler that I want to use is for the D programming language (<a href="http://www.digitalmars.com/d/">http://www.digitalmars.com/d/</a>), and already uses LLVM to generate ELF code and DWARF information on Linux (<a href="https://bitbucket.org/prokhin_alexey/ldc2/wiki/Home">https://bitbucket.org/prokhin_alexey/ldc2/wiki/Home</a> is the home of the compiler, which is not bug free but very complete). </div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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…<br>

<br></blockquote><div><br></div><div>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?</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>Comments welcome.</div><div><br></div><div>Thanks guys.</div><div><br></div><div>Jason</div><div> </div></div>