I'm not sure what side of the interface you need an API for. You can find the LLVM source in llvm/lib/ExecutionEngine/JIT/JITDebugRegisterer.(cpp|h). If your use case is to do your own codegen and then throw some debug info over to the debugger, you'll have to be able to generate it (ie DWARF) and wrap it in the native object file for your platform in memory. LLVM has some code to produce ELF, so I used that.* At the time, I wasn't worried about other platforms.
* Actually, that code for ELF generation is old and this interface is the last user of it so far as I know. Reid On Wed, Mar 16, 2011 at 3:02 PM, Jason E. Aten <[email protected]> wrote: > Thank you Reid, that makes alot of sense now. Is there an API to the JIT > functionality? If so, > could you point out where in the code base it lives, and if there are > examples of clients (how to > use it?) > Thanks! > Jason > > On Wed, Mar 16, 2011 at 1:58 PM, Reid Kleckner <[email protected]> > wrote: >> >> On Wed, Mar 16, 2011 at 2:52 PM, Jason E. Aten <[email protected]> wrote: >> > Jim, thank you--that makes alot of sense. I hadn't thought through the >> > signal implications. And re-reading Reid's post, he does make it clear >> > that >> > the JIT-code injection is somehow a part of an interprocess >> > communication. >> > The question then becomes, does the DNB.h protocol support the JIT-code >> > injection, or if not, could that be a part of it? >> >> Yup, it works similar to the way debuggers find out about dynamically >> loaded libraries. There's a particular loader stub that gets called >> after every library load or unload. Debuggers put a breakpoint on it >> to stop the inferior process and re-read the list of loaded libraries >> with remote memory examination routines, so there's your (hacky) IPC. >> >> Reid > > > > -- > Jason E. Aten, Ph.D. > > > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
