[LLVMdev] debugging LLVM-JITted code

[Eli Bendersky]

>
> So where should I look for adding such support? Is MC JIT the direction?
> Does it purport to emit DWARF as well as executable code? Any pointers to
> relevant places in the code would be most appreciated.
>
>
> MC JIT is the direction that the JIT will be going in the future. Right now
> any debugging emission is minimal at best. My ideas here would be to emit
> the debug info as a section in memory and point the debugger at that.
>

Hi Eric, thanks for answering.
Suppose I would like to prototype adding such functionality to LLVM - where
in the code would be the best place to start? Any existing interfaces that
should be reused/implemented/extended here?


> Note: I'm aware there's an alternative approach - generating a "true"
> shared lib with LLVM's toolchain dynamically and loading it. It has its pros
> and cons vs. generating DWARF directly with the JITted code, and in this
> question I'm focusing on the latter.
>
>
> *nod* Ultimately I think the two will be similar, just the destination of
> the jitted code - static in memory or shared on disk. It's just a matter of
> communicating to the debugger where the debug information resides and having
> the code emitter output the debug information.
>
> With MC JIT I don't think getting it to emit the debug information will be
> particularly hard so you might want to look into it.
>

AFAIU one aspect where the two approaches are somewhat different is with
relocation of debug information (since DWARF seems to need relocation). I.e.
when generating the shared lib, run-time relocation will be handled by the
dynamic loader. To generate DWARF into memory with MC JIT one has to
essentially perform this relocation manually, since the generated DWARF has
to point at the final addresses where code & data are located. What are your
thoughts on this?

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110913/9e9f9073/attachment.html>