Request for feedback on debug info issues

IR & Optimizations
1

Stephen Kell and I have been working on a new approach to test debug info of optimised programs which we believe will help with identifying debug info handling bugs in LLVM optimisation passes. We plan to share more details of our approach in the near future, and we will publish the tools we have developed for everyone in the community to use.

We have filed several issues that we found using our technique so far:

It would be great to get some initial feedback from the LLVM debug info community on these issues. For example…

  • Do they seem like valid issues? If they do, a comment on each issue will help us keep track of which are confirmed to be valid. If they do not, let’s discuss this either on each problematic issue or over here so we can improve future reports.
  • Do they appear to contain enough detail to investigate further? If they do not, what additional info would you like to see?

Feel free to provide feedback in whatever way is easiest for you. :slightly_smiling_face:

Assuming there’s general agreement that these issues are valid and useful, we’ll continue to report more as we discover them. We’re also planning to pursue fixes for these issues together with the community.

We hope to do much more than just file and fix bugs. If you have any ideas for tooling that would help with triaging and fixing these kinds of issues, please do let us know. For example, we’ve considered building debug-info-focused tools such as enhanced pass bisection to find the one responsible for a failure, and also enhanced version bisection to spot when a issue first appeared.

Beyond tooling, we also intend to explore various architectural changes to LLVM debug info handling that will hopefully make these kinds of failures much less likely. We will share more info on these ideas at a later date. Any changes we’re attempting to merge upstream would start first with an RFC thread to ensure the approach is agreeable to the community.

Thanks for your time and effort towards more reliable debugging with LLVM-based tools. :smile:

2

/me scratches head – it looks like the llvmbot comment isn’t generating a team_mention email? Sorry for appearing to ignore those issues, they weren’t on my radar at least.

Many thanks for doing things in the debug-info space, it’s ripe for extra and improved tooling!

3

@jmorse Referring to the github issues? The debuginfo label looks like it generates a mail-to-subscribers action (I seem to get them), and AFAICT you’re on the subscriber list. You might double check with the admins to make sure you’re on there correctly.

4

Ah no worries, I wasn’t sure if someone was intending to react to every debug info issue or not, so that’s partly why I messaged here to highlight them.

About issue notifications, personally I’ve been using the label-based notifications feature that has been enabled for the LLVM repo. I’m not sure of the state of the llvmbot messages to the @llvm/issue-subscribers-debuginfo team, as I don’t use that method myself.

Thanks for reviewing each of the issues above. It’s very helpful to have your feedback! :smile:

5

I’m pretty sure that defect led MLIR to require debug info metadata for all instructions (though I don’t work with MLIR and may be misremembering.

These are definitely super common issues in LLVM; I frequently use godbolt.org and see lines that aren’t highlighted with clang which is indicative of dropped debug info.

1 Like