Tracking Issue for short backtraces in the default panic hook
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
This is a tracking issue for short backtraces in the default panic hook (https://github.com/rust-lang/rust/issues/124586, https://github.com/rust-lang/compiler-team/issues/818). See previous Zulip discussion.
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.
Steps
Compile-time
- Parse, validate, and emit the new
#[rustc_{skip,start,end}_short_backtrace]attributes in rustc itself (https://github.com/rust-lang/rust/pull/134831). Currently blocked on everything else. - Extend LLVM to emit the appropriate debuginfo (https://github.com/llvm/llvm-project/pull/123683)
- Waiting on pre-RFC
- Extend rustc_codegen_cranelift to emit the appropriate debuginfo (https://github.com/rust-lang/rust/pull/134831). Blocked.
- Extend rustc_codegen_gcc to emit the appropriate debuginfo. Waiting on me or Antoyo to implement it.
Runtime
- Extend either addr2line or gimli to give backtrace-rs a way to find the appropriate debuginfo (https://github.com/gimli-rs/gimli/pull/756). Waiting on me to rework the API in response to review comments.
- Update backtrace-rs to pass the debuginfo through to libstd (https://github.com/rust-lang/backtrace-rs/pull/693). Waiting on the gimli PR and for me to have time to debug this on macOS.
- Update the default panic hook to use the debuginfo (https://github.com/rust-lang/rust/pull/134831). Blocked on everything else.
Unresolved Questions
- How should we represent the debuginfo at runtime? The current three-state enum doesn't allow both marking a frame as the end of a push/pop pair while also omitting it in the backtrace. NOTE: please leave comments about this on LLVM discourse, not on this issue.
- How can we extend this to PDB? Right now it only works for DWARF. Possibly we can use
llvm.codeview.annotation?
Implementation history
See above.
@rustbot label T-compiler T-libs A-runtime A-backtrace A-debuginfo
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the unchecked compile-time and runtime items, especially rust-lang/rust PR 134831, the LLVM pre-RFC, and the linked gimli and backtrace-rs PRs. Done requires resolving the listed compiler, debuginfo, runtime, and panic-hook dependencies, but the issue shows that several remain blocked or under discussion.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100