Debug info roundtable at 2023 EuroLLVM

Community EuroLLVM
,
2

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