Page MenuHomePhabricator

[WIP] [DebugIR] Revive the old DebugIR pass for tip-of-tree LLVM.
AbandonedPublic

Authored by bollu on Nov 18 2017, 5:29 AM.

Details

Summary

This is a revival of the old DebugIR pass.

This pass strips away old debug info, and inserts new debug info that provides LLVM IR level
debugging in a debugger.

I do not fully understand the debug infrastructure of LLVM, so reviews will be much appreciated!

Event Timeline

bollu created this revision.Nov 18 2017, 5:29 AM
bollu added a subscriber: debug-info.
philip.pfaffe edited edge metadata.Nov 20 2017, 3:18 AM

If this is going back into LLVM, it should also be a NewPM Pass.

vsk edited edge metadata.Nov 27 2017, 10:42 AM

@bollu On llvm-dev, you mentioned that the use case for this pass is to debug a frontend. The standard frontend testing strategy is to write targeted lit tests for source constructs and FileCheck the IR. Does that not work for your frontend? Do you know of other frontends which use a 'DebugIR'-like strategy?

IMO there are some serious technical issues with this patch, but I'd like to understand the use case a bit better before delving into them.

@vsk I do use the same technique for testing my frontend. However, this is useful when stuff _breaks_ in the frontend.g I'm not as good at reading asm as I'd like to be, so being able to debug at the IR level is a boon.

vsk added a comment.Nov 27 2017, 1:06 PM

The bugpoint tool can create reduced test cases for frontend IR-generation bugs. Is that also not sufficient?

bollu added a comment.Nov 27 2017, 1:49 PM

@vsk Bugpoint does has four weaknesses that I have noticed not work (as far as I know, please do let me know if bugpoint can do this)

  1. If one has to load an external library that the code depends on, bugpoint cannot do this since lli cannot do this.
  2. There is no way to guide bugpoint, so it might expose other bugs that you do not care about right now. This becomes a wild goose chase in some complex situations.
  3. Bugpoint cannot "handle" non-determinism, and it is unrealistic to expect it to do so.
  4. one cannot debug miscompiles with bugpoint, you *have to* read the asm / output LLVM IR to see what is going on. In such situations, source stepping is *way* better.

Plus, often, it is helpful to chuck some IR into the debugger to trace what's going on "live".

vsk added a comment.Nov 27 2017, 2:19 PM

@vsk Bugpoint does has four weaknesses that I have noticed not work (as far as I know, please do let me know if bugpoint can do this)

  1. If one has to load an external library that the code depends on, bugpoint cannot do this since lli cannot do this.
  2. There is no way to guide bugpoint, so it might expose other bugs that you do not care about right now. This becomes a wild goose chase in some complex situations.
  3. Bugpoint cannot "handle" non-determinism, and it is unrealistic to expect it to do so.
  4. one cannot debug miscompiles with bugpoint, you *have to* read the asm / output LLVM IR to see what is going on. In such situations, source stepping is *way* better.

    Plus, often, it is helpful to chuck some IR into the debugger to trace what's going on "live".

I don't mean to say that bugpoint can replace a debugger, just that it's powerful enough to create reduced test cases for complex frontend bugs. Regarding your second point, you can in fact guide bugpoint by using the custom-compile option (see http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html).

To your fourth point, debugging a miscompile necessarily involves looking at IR (even with a DebugIR pass), and possibly at assembly. The best way to reduce the amount of IR/assembly that needs to be investigated is to bisect the program against a last-known-good-revision of the frontend. That facilitates extracting a reduced test case for the bug.

bollu added a comment.Nov 28 2017, 5:01 AM

@vsk In that case, I think we agree. Bugpoint is useful, but a debugger is really helpful in certain contexts. It's easier for me (and I suspect others) to debug on the IR level when they would like to do so. Does that provide enough of a motivation to go ahead with the review of the patch? You mentioned that there are technical issues, I'd like to sort them out :)

Please remember to subscribe llvm-commits on patches. Especially for a new pass, this deserves wider awareness.

I think you have to recommit this, since phabricator doesn't send out the original patch if you forget to add llvm-commits up front :(

vsk added a comment.Nov 28 2017, 10:32 AM

@bollu I don't think we're on the same page yet, but we can continue the discussion on a new Phab thread with llvm-commits CC'd.

bollu abandoned this revision.Dec 3 2017, 1:46 PM

Sorry for the delay, I resubmitted the patch as D40778. I'm closing this in favor of continuing the discussion there. Ping, @vsk, and thanks for all the help so far!