[llvm-dev] Reviving the DebugIR pass

Thu Mar 22 11:42:24 PDT 2018

+ 1 to having this functionality implemented as `llvm-as -g` or some analog (`clang -g foo.ll`).

As I outlined in https://reviews.llvm.org/D40778 <https://reviews.llvm.org/D40778>, I think such a solution can be made to work for JIT users who don't have on-disk *.ll files.

> On Mar 21, 2018, at 5:37 PM, Jason Surprise via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> We have implemented a debug pass to enable debugging of jitted functions. The pass dumps the IR of the module at the beginning of the pass, which then becomes the source code for the debug metadata. Our solution focuses on a windows x86 solution but I’m sure it would be easy to extend to other platforms.
> 
> In order to load the resulting debugging info into Visual Studio, we jit to object file then offline use msvc linker to create a dll with debugging symbols. We then load the dll into the running executable. At that point most debugging facilities are available, such as setting breakpoints, stepping through IR or assembly, etc.
> 
> With our workflow we jit a substantial amount of functionality and having the ability to debug IR has been very useful.  I could work on making this open source if there is interest. 
> Thanks,
> Jason
> 
> On Mar 21, 2018, at 4:51 PM, Jonas Devlieghere via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>> Hi Dan,
>> 
>> Having missed this functionality myself in the past I’m excited to see this gain traction. Let me know if there’s anything I can do to help this along. 
>> 
>> Cheers,
>> Jonas
>> 
>> On Wed, 21 Mar 2018 at 18:19, Dan Liew via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> Hi,
>> 
>> I recently had the need to see the correspondence between some Clang
>> generated LLVM IR and the compiled machine code within a debugger
>> (lldb in this case). Unfortunately it looks like the functionality to
>> do this used to be in a pass called 'DebugIR' but was removed due to
>> the lack of a maintainer [1].
>> 
>> It appears an attempt was made [2] to revive this but it appears to
>> have stalled.
>> 
>> I am very keen to see this feature land back in LLVM, so I'd either
>> like to take over [2] (only if the original author is no longer
>> interested) or rewrite the feature from scratch based on feedback on
>> what the community needs.
>> 
>> The use cases for this feature I see are:
>> 
>> * Debugging instrumentation inserted by LLVM passes. This is my use
>> case. I need to debug ASan instrumentation so looking at the original
>> source code in lldb is pretty useless because I can't see the
>> instrumentation. Looking at the LLVM IR on the otherhand is very
>> useful because I can see the ASan instrumentation at a (slightly)
>> higher level than the native machine code assembly.
>> 
>> * Debugging JIT'ed code. The LLVM IR that is JIT'ed might not come
>> from a higher level language and might be generated directly. In this
>> case the only debug information that makes sense is the LLVM IR
>> representation of the JIT'ed LLVM IR. This might be a bit tricky
>> though because there might not be an on disk representation of the
>> LLVM IR.
>> 
>> * Writing portions of a runtime in LLVM IR. This is not something I
>> advise doing but sometimes its necessary to write parts of a compiler
>> runtime in LLVM IR when it is difficult to write the equivalent code
>> in a higher level language. This is something I've had to do in KLEE
>> before because I couldn't get Clang to emit the LLVM IR in the precise
>> form that I wanted.
>> 
>> Debug information is not really my expertise but I'm happy to become
>> the code owner/maintainer of whatever implementation we end up with
>> (so that it doesn't get removed again) if necessary.
>> 
>> This work could also be used to fix [3]. Although this probably needs
>> more though because there's the question of whether we should preserve
>> existing debug information in an LLVM IR file or write over it when it
>> is given to Clang.

If foo.ll contains edited debug info, `clang -g` shouldn't silently drop the edits. A warning + no-op seems more appropriate.

Happy to help with code review!

thanks,
vedant

>> 
>> Any thoughts on this?
>> 
>> [1] https://reviews.llvm.org/rL222945 <https://reviews.llvm.org/rL222945>
>> [2] https://reviews.llvm.org/D40778 <https://reviews.llvm.org/D40778>
>> [3] https://bugs.llvm.org/show_bug.cgi?id=35770 <https://bugs.llvm.org/show_bug.cgi?id=35770>
>> 
>> Thanks,
>> Dan.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> -- 
>> Sent from my iPhone
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20180322/30429605/attachment-0001.html>