There will be a debug info roundtable at EuroLLVM later this week. The discussion is scheduled for 11:00 - 11:30 on Thursday (11 May).
The high-level agenda I have in mind at the moment includes topics such as:
- Current status of debug info projects
- Long-term direction of debug info
- Ideas for tooling to make debug info more reliable
If there’s something you’d like to discuss, please do let me know. I’ll do my best to take notes and share those here after the event.
I’m looking forward to seeing other debug info community members there! 
2 Likes
Thanks to everyone who attended the roundtable! As you can see, it was quite a sizeable group this year. I have included my notes below. I may have missed some points or represented them incorrectly, so please let me know if you have questions or corrections.
Attendees
- J. Ryan Stinnett (King’s College London)
- Stephen Kell (King’s College London)
- Hans Wennborg (Google, Chrome)
- Orlando Cazalet-Hyams (SN Systems / Sony)
- Martin Storsjö (independent)
- Tobias Hieta (Ubisoft)
- Carlos Alberto Enciso (SN Systems / Sony)
- Kirill Shmakov (JetBrains)
- Michael Buch (Apple)
- Greg Bedwell (SN Systems / Sony)
- Andrei Lebedev (Access Softek)
- Jermey Morse (SN Systems / Sony)
- Stephen Tozer (SN Systems / Sony)
- Luke Brown (Opera)
- Fahad Nayyar (Apple)
- Eduardo Blázquez (U. of Madrid)
- Javier Lopez Gomez (CERN, Cling)
- Maurice Heumann (Wibu-Systems)
- Michal Rostecki (independent)
- Nicola Rossi (Solid Sands)
- Matthew Arsenault (AMD)
- Jeroen Dobbelaere (Synopsys)
- Jonas Devlieghere (Apple)
- Petr Hosek (Google, Fuchsia)
Notes
- Experiences at Ubisoft
- TH: Clang seems to have worse debug info than MSVC
- Current status of debug info projects
- Long-term direction of debug info
- Issues with current IR design
- Assignment location discarded too early
- GB: Better to drop if else
- OCH: Line numbers aren’t used
- JM: Two level line tables may help for instruction with multiple source positions
- AL: Tried to present this in the past, but no decision taken
- ST: Debug info is large, so if you try cram even more info in…
- JM: Alexei has a DWARF linker that compacts redundancy, but too slow
- SK: Line number tables can be extended like location views
- ST: Inlined calls sites have no debug info, line table extensions could help with that
- Unable to represent assignments that happen on critical edges
- JM: Block gets deleted, nowhere to represent it today
- JM: Does show up in tests
- Can’t describe multiple simultaneous locations
- Compare with MLIR debug info
- Roundtable audience is LLVM IR focused, separate investigation needed here
- GB: Polling people actually able to work on debug info improvements
- Seemed like 8 or so out of ~30
- TH: Constants are poorly represented with CodeView / PDB
- OCH: Some passes mess with globals, perhaps that’s affecting this
- ST: Passes that affect globals have negative effects
- JM: Patch from 2017 for extended lifetimes by adding fake uses
- JM: Community response at the time was to make variable locations better overall instead
- ST: 2% more compiler time for 20% better debug info
- SK: Could imagine way for debugger to save values instead
- ST: Would need fast breakpoints
- ST: Also need to consider case where several blocks join without debug info
- Ideas for tooling to make debug info more reliable
- Our testing approach
- Enhanced pass bisection to find the one responsible for a failure
- Enhanced version bisection to spot when a issue first appeared
- TH: Compare DWARF outputs to PDB outputs
- JRS: Could perhaps use Carlos’s debug view tool to compare
- CAE: May be hard since the tool runs at the very end
- CAE: Line number of definition is missing
- ST: Changing formats could give a decent answer
- JM: Something to measure: visible in scopes
- JRS: Definitely actively interested in this
- JM: Where do you step? Are the variables actually visible?
- ST: Source line stepping attribution
- AL: Definitely a common issue
- ST: Could have correct line attribution, but might look confusing
- GB: With inlining, can get very confusing
- TH: Our code is lambda heavy, that can have very strange jumping
- SK: Does lambda just not appear in the call stack?
- TH: Lambda might get removed, variables might not appear
- TH / ST: Sometimes mark parts to disable debugging
- ST: Og could also be about switching flags on to improve debugging
- GB: What perf drop would users accept?
- TH: 5 - 6% drop is apparently too much for our users
- ST: Could have flag to disable optimisation for a subset of code
- AL: Has someone explored debug info quality for heavy cases like LTO?
- ST: Haven’t done so yet
- OCH: Brief look, but not much
- JD: On some platforms (Apple), LTO’d debug info doesn’t pass verification
- GB: Could explore mode in scheduler that puts barriers around inlined code so that you don’t jump around between functions
- ST: Inlining makes debug info much worse, but also important optimisation for performance
- JM: Cases of dropped source location because hoisting / sinking
- GB: Original motivation for setting to 0 for profiling correctness
- JM: Two level line tables may help here
- JD: Has anyone prototyped two level?
- ST: Yes, worked well for stepping on inlined call site that has been optimised away
- JM / ST: Will investigate sharing with the community
- JD: Interested in having this on the debugger side
- PH: Often stepping through things that don’t appear in call graph
- Two level line table should help
- ST: When we merge instructions, no way to attribute both source locations
- GB: Better than no lines at least
- PH: Really want to see implicit pointer support patches landed
- JM: May need to rework patches a bit, but yes would be good to have
1 Like
Thanks @jryans for organizing the round table and taking notes!
1 Like