[llvm-dev] Debugging JIT'ed code with ORC JIT?

Lang Hames via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 11 11:28:01 PDT 2017


Oh, you're right though: The possibility of doing this is all in my head,
but not well documented anywhere yet. :/

-- Lang.

On Wed, Oct 11, 2017 at 11:26 AM, Lang Hames <lhames at gmail.com> wrote:

> HI Yichao,
>
> RTDyldObjectLinkingLayer has a NotifyObjectLoaded hook that you can use to
> call NotifyObjectEmitted on your GDBRegistrationListener.
>
> If code is going to be unloaded we would have to add an extra hook to call
> NotifyFreeingObject -- that seems totally reasonable to add.
>
> -- Lang.
>
>
> On Wed, Oct 11, 2017 at 10:44 AM, Yichao Yu <yyc1992 at gmail.com> wrote:
>
>> > What debugging support MCJIT has is provided by the RuntimeDyld utility,
>> > which ORC shares. I would expect anything in that document to apply to
>> ORC
>> > as well, though I haven't tested it personally.
>>
>> I'm pretty sure that's not the case, at least not with any simple
>> orcjit tutorials I've seen.
>>
>> The GDB support is provided by `GDBJITRegistrationListener` which is
>> registered to MCJIT directly in the constructor and AFAICT no where
>> else. Also, since there doesn't seem to be a default (non-noop)
>> implementation of `ExecutionEngine::RegisterJITEventListener` I
>> believe you can't just call `RegisterJITEventListener` on non-MCJIT
>> and expect it to work.
>>
>> So while I totally believe one can use
>> `JITEventListener::createGDBRegistrationListener()` to hook the JIT
>> with the the gdb registration function, it won't work without writing
>> code to explicitly do that (in additional to actually writing code to
>> interface with the event listener directly). OTOH though when using
>> MCJIT, this is done by default and one don't need to write any code
>> for it to work.
>>
>> >
>> > For what it's worth, this is something I'm interested in and hope to
>> make
>> > some progress on in tree in the not too distant future.
>> >
>> > -- Lang.
>> >
>> > On Mon, Oct 9, 2017 at 12:27 PM, Jameson Nash via llvm-dev
>> > <llvm-dev at lists.llvm.org> wrote:
>> >>
>> >> That is correct – there is no built-in support. You have to provide
>> your
>> >> own Registrar to the ObjectLinkingLayer to provide this sort of
>> >> functionality. (For example JuliaLang does that at
>> >> https://github.com/JuliaLang/julia/blob/1216e5f60cd2b23e2985
>> 6b5227399ab0f3abef76/src/jitlayers.cpp#L437,
>> >> in addition to registering the function pointer and object file info in
>> >> several other places).
>> >>
>> >>
>> >> On Sun, Oct 8, 2017 at 11:48 PM Connor Gray via llvm-dev
>> >> <llvm-dev at lists.llvm.org> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I’m wondering if it’s possible to debug code JIT’ed with the newer ORC
>> >>> JIT. The LLVM documentation has a page at
>> >>>
>> >>>     llvm.org/docs/DebuggingJITedCode.html
>> >>>
>> >>> showing an example of using gdb to debug MCJIT’ed code, but has no
>> >>> mention of ORC JIT.
>> >>>
>> >>> From searching around online I’ve gotten the impression that ORC JIT
>> does
>> >>> *not* support providing debugging information to attached debuggers,
>> but no
>> >>> definitive source. Is it the case that ORC JIT in fact does support
>> >>> debugging, and if so, are there examples available; or is my initial
>> >>> impression correct?
>> >>>
>> >>> Thanks,
>> >>> Connor
>> >>> _______________________________________________
>> >>> LLVM Developers mailing list
>> >>> llvm-dev at lists.llvm.org
>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> llvm-dev at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>
>> >
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171011/8a5e17ea/attachment.html>


More information about the llvm-dev mailing list