Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent behavior across platform of split-debuginfo #114215

Closed
roblabla opened this issue Jul 29, 2023 · 1 comment · Fixed by #115120
Closed

Inconsistent behavior across platform of split-debuginfo #114215

roblabla opened this issue Jul 29, 2023 · 1 comment · Fixed by #115120
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. O-linux Operating system: Linux O-macos Operating system: macOS O-windows Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@roblabla
Copy link
Contributor

Setting up a release profile with stripped binaries and split debuginfo is made very complicated due to subtle differences in how debug, strip and split-debuginfo interact with eachother across platforms. In particular, in the following setup:

[profile.release]
split-debuginfo = "packed"
strip = "symbols"
debug = "limited"

Then when targetting linux/macos, a .dwp/.dSYM debug information file will be generated, while when targeting windows, no debug information file can be found. In particular, no .pdb file is created.

This seems to stem from how the flags propagate to linker invocation:

  • On windows, the debuginfo function of rustc_codegen_ssa only takes strip into account when choosing how to generate the debug information. If it's set to any value other than None, it will not generate any debuginfo whatsoever, regardless of the value of split-debuginfo.
  • On macos/linux, it's rustc_codegen_ssa::back::link_natively that's responsible both for splitting debuginfo and stripping. A .dSYM/.dwp file will be created only if debug is set to a value other than 0, and split-debuginfo is set to packed. Stripping is, crucially, not a part of the equation.

I believe the behavior with the windows should be adjusted to match what is done on macos/linux. In particular, if split-debuginfo is set to packed and strip is set to symbols, then a pdb file should be generated.

Meta

rustc --version --verbose:

rustc 1.71.0 (8ede3aae2 2023-07-12)
binary: rustc
commit-hash: 8ede3aae28fe6e4d52b38157d7bfe0d3bceef225
commit-date: 2023-07-12
host: aarch64-apple-darwin
release: 1.71.0
LLVM version: 16.0.5
@roblabla roblabla added the C-bug Category: This is a bug. label Jul 29, 2023
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jul 29, 2023
@workingjubilee workingjubilee added O-windows Operating system: Windows O-linux Operating system: Linux O-macos Operating system: macOS T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) WG-debugging Working group: Bad Rust debugging experiences and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. WG-debugging Working group: Bad Rust debugging experiences labels Jul 29, 2023
@segevfiner
Copy link
Contributor

I believe split-debuginfo = "unpacked" is also effected by such inconsistencies. Would be nice to have consistent behavior. And possibly a strip flag that produces both an unstripped and stripped binary, though that's a separate feature.

@bors bors closed this as completed in 7f2fc33 Apr 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. O-linux Operating system: Linux O-macos Operating system: macOS O-windows Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants