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

[Reid Kleckner]

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 <j.e.aten at gmail.com> 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 <reid.kleckner at gmail.com>
> wrote:
>>
>> On Wed, Mar 16, 2011 at 2:52 PM, Jason E. Aten <j.e.aten at gmail.com> 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.
>
>
>