On Wed, Mar 16, 2011 at 2:18 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:reid.kleckner@gmail.com">reid.kleckner@gmail.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;">
If your use<br>
case is to do your own codegen and then throw some debug info over to<br>
the debugger, you'll have to be able to generate it (ie DWARF) and<br>
wrap it in the native object file for your platform in memory. LLVM<br>
has some code to produce ELF, so I used that.* At the time, I wasn't<br>
worried about other platforms.<br>
<br>
* Actually, that code for ELF generation is old and this interface is<br>
the last user of it so far as I know.</blockquote><div><br></div><div>Great! Yes, that is exactly my use case: Suppose I am stopped in the middle of code, in LLDB,</div><div>with a variable that has a debugger symbol for a collection that needs to be sorted differently than it is at the moment, in order</div>
<div>to determine if the code is producing the correct collection.</div><div><br></div><div>So I'd like to be able to define a new sorting function from the command line (like the Clang Expression stuff I think let's one do), but</div>
<div>in this case it's in a non-C++ language that I have a compiler for. Then JIT-compile that new "how to sort" function, and have it talk to already</div><div>defined data and code, and have it run from the within the debugger. After the sort, be able (from LLDB) be able to re-inspect the</div>
<div>output of the collection.</div><div><br></div><div>Does this make sense? Are there obstacles that I'm not envisioning? Any critique or commentary welcome.</div><div><br></div><div>Since I'm on Linux, ELF works perfectly, and I already have ELF codegen that produces Ahead-of-time compiled ELF's now, I just need to figure out how to convert that to use the JIT engine instead, I presume. I assume I would need to produce an in-memory .so dynamically loaded library format file then. Does that sound right? </div>
<div><br></div><div>Lastly, could the JITDebugRegisterer.(cpp|h) functionality be made a part of the DNB.h interface?</div><div><br></div><div>Thanks,</div><div>Jason</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="h5">
On Wed, Mar 16, 2011 at 3:02 PM, Jason E. Aten <<a href="mailto:j.e.aten@gmail.com">j.e.aten@gmail.com</a>> wrote:<br>
> Thank you Reid, that makes alot of sense now. Is there an API to the JIT<br>
> functionality? If so,<br>
> could you point out where in the code base it lives, and if there are<br>
> examples of clients (how to<br>
> use it?)<br>
> Thanks!<br>
> Jason<br>
><br>
> On Wed, Mar 16, 2011 at 1:58 PM, Reid Kleckner <<a href="mailto:reid.kleckner@gmail.com">reid.kleckner@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Wed, Mar 16, 2011 at 2:52 PM, Jason E. Aten <<a href="mailto:j.e.aten@gmail.com">j.e.aten@gmail.com</a>> wrote:<br>
>> > Jim, thank you--that makes alot of sense. I hadn't thought through the<br>
>> > signal implications. And re-reading Reid's post, he does make it clear<br>
>> > that<br>
>> > the JIT-code injection is somehow a part of an interprocess<br>
>> > communication.<br>
>> > The question then becomes, does the DNB.h protocol support the JIT-code<br>
>> > injection, or if not, could that be a part of it?<br>
>><br>
>> Yup, it works similar to the way debuggers find out about dynamically<br>
>> loaded libraries. There's a particular loader stub that gets called<br>
>> after every library load or unload. Debuggers put a breakpoint on it<br>
>> to stop the inferior process and re-read the list of loaded libraries<br>
>> with remote memory examination routines, so there's your (hacky) IPC.<br>
>><br>
>> Reid<br>
><br>
><br>
><br>
> --<br>
> Jason E. Aten, Ph.D.<br>
><br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jason E. Aten, Ph.D.<br><br><br>