wg-debugging 2022-06-06 meeting

--- tags: debugging --- # wg-debugging 2022-06-06 meeting ## Agenda - Next upcoming meeting: Triage meeting on Mon June 20th, 10am ET. - Text meeting in the Zulip channel. - Last meeting we covered 5 issues (closed 2, created new issue for 1, created PR to close 1) - We're hoping to identify more "easy" to resolve issues by working through the backlog. - Next design & status meeting: Mon July 5th, 12pm ET. - We'll try to alternate between the Monday & Tuesday timeslots. ## Notes - Rust support in LLDB - 2018: https://discourse.llvm.org/t/rust-language-support-question/47479 - 2019: https://lists.llvm.org/pipermail/lldb-dev/2019-September/015543.html - CI support - source of confusion: if a debugger is missing, test is just ignored, not a fail. Thus, the testing you see locally may be totally different from what CI does - in particular, current CI has: lldb testing on Mac (alone), gdb testing on Linux (alone) and cdb on Windows (alone). - why no lldb on Linux? Not clear. - none of the above is Visual Studio (but that's not really our problem to solve...) - wesley: Swift support is for... - e.g. autocompletion? expression evaluation? - or does it handle e.g. "instruction pointer is here", "variables are here"? Or does it continue to use DWARF for that? - wesley: in Rust's use of LLVM, Rustc doesn't see the answers to the latter questions; LLVM is a blackbox and handles how all that is resolved, and emits correlated DWARF - david: from vague memory/understanding, the ASTContext actively punches holes in the abstraction described above. ## (original notes that were called Action Items) - Review email threads above and understand what the sticking points were. - We should try to learn more about how Swift does this. - david barsky says this has promise; main drawback is that it introduces coupling between the (unstable) Swift internal IR used to compile the particular object code and the debugger itself - (this sounds like something that might be well-addressed by stable-mir - would be good to add *somewhere* in the stable-mir roadmap - Apple's fork of LLVM has the source: https://github.com/apple/llvm-project/tree/790d0318eb1134a30de7a4ea9c800df750eec29c/lldb/source/Plugins/TypeSystem - if we take the Swift-on-lldb approach, can that be applied to other debuggers like gdb and cdb (aka WinDbg) - Wesley: might be able to apply similar story, but the API's are completely different for the different debuggers... - this just means that the act of loading the MIR support would be debugger specific. Once its loaded, it might be able to dispatch to some shared code base for e.g. expression-evaluation, type-inspection, etc. - We don't have a write-up of the problems we're trying to solve (e.g. expression evaluation) - There's a backlog of issues that people have filed in terms of debugger support - broad groups (from internal Facebook surveys) - people learning Rust who expect a working debugger as part of their tooling. ("How did my program get to this point?") - people who know Rust reasonably well and are trying to deploy Rust to an embedded target (e.g. Apple WatchOS) where their Rust code is interacting with a closed source library and want to understand what's happening *there* - pnkfelix started some notes last year on Debugging in Rust, might be a place to start for such a write-up: https://hackmd.io/4U3fNjNsTwGyTuQadtNzIw?both ## Action Items - [ ] wesley: write up the problems we are trying to solve. - [ ] davidtwco: speak Ryan about what to do once survey questions are complete, and then write Inside Rust blog post. - [ ] pnkfelix: Review email threads above and understand what the sticking points were. - [ ] davidtwco+dbarsky: Review Swift model for debugging support and how Rust might adopt it - [ ] pnkfelix: request wg-debugging repo under rust-lang (for storing issues, meeting notes, and other work) - Filed issue with rust-lang/infra: https://github.com/rust-lang/infra-team/issues/59