Tracking issue for `-Zdwarf-version` #103057

pnkfelix · 2022-10-14T14:23:52Z

This is a tracking issue for the -Zdwarf-version unstable flag (no RFC/MCP) added in #98350 which allows selecting the specific version of DWARF to use when creating debuginfo.

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

Initial implementation (Implement support for DWARF version 5. #98350)
Wider Testing (tested on RfL)
Adjust documentation (see instructions on rustc-dev-guide) (Stabilize -Zdwarf-version as -Cdwarf-version #136926)
Stabilization PR (see instructions on rustc-dev-guide) (Stabilize -Zdwarf-version as -Cdwarf-version #136926)

Unresolved Questions

Is the pre-compiled standard library (potentially) using a different version of DWARF an issue?
What should the behavior of the flag do when the active target does not use DWARF?

Implementation history

Initial implementation: Implement support for DWARF version 5. #98350
Stop emitting .debug_pubnames and .debug_pubtypes when using DWARF 5 fix: stop emitting .debug_pubnames and .debug_pubtypes #117962
Refactoring & cleanups Clean up uses of the unstable dwarf_version option #135739
Fix LLVM warning on LTO with different DWARF versions Pick the max DWARF version when LTO'ing modules with different versions #136659
Improve argument validation Emit an error if -Zdwarf-version=1 is requested #136746

The text was updated successfully, but these errors were encountered:

thomcc · 2022-11-10T19:42:47Z

Ideally this design proposal would include some method of exposing it to cargo build scripts, so crates like cc would be able to use the right version of DWARF (see rust-lang/cc-rs#694, for example, where we hardcode decisions compatible with rustc)

Wyvern · 2023-02-03T17:25:52Z

Is there a unstable way to opt-in DWARF5 for Rust now?
Tried -Zdwarf-version=5 in macOS, but seems failed.

Rust 1.64.0 introduced (unstable) support for the `-Zdwarf-version` flag, which allows to select DWARFv5, thus use it. Link: rust-lang/rust#103057 Link: rust-lang/rust#98350 Signed-off-by: Miguel Ojeda <[email protected]> Link: https://lore.kernel.org/r/[email protected]

Rust 1.64.0 introduced (unstable) support for the `-Zdwarf-version` flag, which allows to select DWARFv5, thus use it. Link: rust-lang/rust#103057 Link: rust-lang/rust#98350 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>

Rust 1.64.0 introduced (unstable) support for the `-Zdwarf-version` flag, which allows to select DWARFv5, thus use it. Link: rust-lang/rust#103057 Link: rust-lang/rust#98350 Reviewed-by: Alice Ryhl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>

fhanau · 2024-12-24T00:03:02Z

As of Xcode 16 DWARFv5 is used by default when targeting macOS 15 or higher, LLVM also defaults to 5 on Linux for most architectures. Hopefully the defaults can be updated to what LLVM is doing soon. This is especially helpful when using linker plugin LTO to link Rust and C++ code together, which produces lots of LLD warnings when there are mismatching Rust versions.

…, r=lqd Clean up uses of the unstable `dwarf_version` option - Consolidate calculation of the effective value. - Check the target `DebuginfoKind` instead of using `is_like_msvc`. - Add the tracking issue to the unstable book page for this feature. cc rust-lang#103057

Rollup merge of rust-lang#135739 - wesleywiser:dwarf_version_handling, r=lqd Clean up uses of the unstable `dwarf_version` option - Consolidate calculation of the effective value. - Check the target `DebuginfoKind` instead of using `is_like_msvc`. - Add the tracking issue to the unstable book page for this feature. cc rust-lang#103057

…e_behavior, r=jieyouxu Pick the max DWARF version when LTO'ing modules with different versions Currently, when rustc compiles code with `-Clto` enabled that was built with different choices for `-Zdwarf-version`, a warning will be reported. It's very easy to observe this by compiling most anything (eg, "hello world") and specifying `-Clto -Zdwarf-version=5` since the standard library is distributed with `-Zdwarf-version=4`. This behavior isn't actually useful for a few reasons: - From observation, LLVM chooses to pick the highest DWARF version anyway after issuing the warning. - Clang specifies that in this case, the max version should be picked without a warning and as a general principle, we want to support x-lang LTO with Clang which implies using the same module flag merge behaviors. - Debuggers need to be able to handle a variety of versions within the same debugging session as you can easily have some parts of a binary (or some dynamic libraries within an application) all compiled with different DWARF versions. This commit changes the module flag merge behavior to match Clang and use the highest version of DWARF. It also adds a test to ensure this behavior is respected in the case of two crates being LTO'd together and adds a test to ensure no warning is printed. Fixes rust-lang#130041 which fails due to these warnings being printed cc rust-lang#103057

Emit an error if `-Zdwarf-version=1` is requested DWARF 1 is very different than DWARF 2+[^1] and LLVM does not really seem to support DWARF 1 as Clang does not offer a `-gdwarf-1` flag[^2] and `llc` will just generate DWARF 2 with the version set to 1[^3]. Since this isn't actually supported (and it's not clear it would be useful anyway), report that DWARF 1 is not supported if it is requested. Also add a help message to the error saying which versions are supported. cc rust-lang#103057 [^1]: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-gdwarf [^2]: https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-gdwarf [^3]: https://godbolt.org/z/s85d87n3a

…e_behavior, r=jieyouxu Pick the max DWARF version when LTO'ing modules with different versions Currently, when rustc compiles code with `-Clto` enabled that was built with different choices for `-Zdwarf-version`, a warning will be reported. It's very easy to observe this by compiling most anything (eg, "hello world") and specifying `-Clto -Zdwarf-version=5` since the standard library is distributed with `-Zdwarf-version=4`. This behavior isn't actually useful for a few reasons: - From observation, LLVM chooses to pick the highest DWARF version anyway after issuing the warning. - Clang specifies that in this case, the max version should be picked without a warning and as a general principle, we want to support x-lang LTO with Clang which implies using the same module flag merge behaviors. - Debuggers need to be able to handle a variety of versions within the same debugging session as you can easily have some parts of a binary (or some dynamic libraries within an application) all compiled with different DWARF versions. This commit changes the module flag merge behavior to match Clang and use the highest version of DWARF. It also adds a test to ensure this behavior is respected in the case of two crates being LTO'd together and adds a test to ensure no warning is printed. Fixes rust-lang#130041 which fails due to these warnings being printed cc rust-lang#103057

Rollup merge of rust-lang#136659 - wesleywiser:dwarf_version_lto_merge_behavior, r=jieyouxu Pick the max DWARF version when LTO'ing modules with different versions Currently, when rustc compiles code with `-Clto` enabled that was built with different choices for `-Zdwarf-version`, a warning will be reported. It's very easy to observe this by compiling most anything (eg, "hello world") and specifying `-Clto -Zdwarf-version=5` since the standard library is distributed with `-Zdwarf-version=4`. This behavior isn't actually useful for a few reasons: - From observation, LLVM chooses to pick the highest DWARF version anyway after issuing the warning. - Clang specifies that in this case, the max version should be picked without a warning and as a general principle, we want to support x-lang LTO with Clang which implies using the same module flag merge behaviors. - Debuggers need to be able to handle a variety of versions within the same debugging session as you can easily have some parts of a binary (or some dynamic libraries within an application) all compiled with different DWARF versions. This commit changes the module flag merge behavior to match Clang and use the highest version of DWARF. It also adds a test to ensure this behavior is respected in the case of two crates being LTO'd together and adds a test to ensure no warning is printed. Fixes rust-lang#130041 which fails due to these warnings being printed cc rust-lang#103057

Emit an error if `-Zdwarf-version=1` is requested DWARF 1 is very different than DWARF 2+[^1] and LLVM does not really seem to support DWARF 1 as Clang does not offer a `-gdwarf-1` flag[^2] and `llc` will just generate DWARF 2 with the version set to 1[^3]. Since this isn't actually supported (and it's not clear it would be useful anyway), report that DWARF 1 is not supported if it is requested. Also add a help message to the error saying which versions are supported. cc rust-lang#103057 [^1]: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-gdwarf [^2]: https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-gdwarf [^3]: https://godbolt.org/z/s85d87n3a

Rollup merge of rust-lang#136746 - wesleywiser:err_dwarf1, r=Urgau Emit an error if `-Zdwarf-version=1` is requested DWARF 1 is very different than DWARF 2+[^1] and LLVM does not really seem to support DWARF 1 as Clang does not offer a `-gdwarf-1` flag[^2] and `llc` will just generate DWARF 2 with the version set to 1[^3]. Since this isn't actually supported (and it's not clear it would be useful anyway), report that DWARF 1 is not supported if it is requested. Also add a help message to the error saying which versions are supported. cc rust-lang#103057 [^1]: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-gdwarf [^2]: https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-gdwarf [^3]: https://godbolt.org/z/s85d87n3a

…n, r=petrochenkov Stabilize `-Zdwarf-version` as `-Cdwarf-version` I propose stabilizing `-Zdwarf-version` as `-Cdwarf-version`. This PR adds a new `-Cdwarf-version` flag, leaving the unstable `-Z` flag as is to ease the transition period. The `-Z` flag will be removed in the future. # `-Zdwarf-version` stabilization report ## What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? No RFC/MCP, this flag was added in rust-lang#98350 and was not deemed large enough to require additional process. The tracking issue for this feature is rust-lang#103057. ## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. None that has been extensively debated but there are a few questions that could have been chosen differently: 1. What should the flag name be? The current flag name is very specific to DWARF. Other debuginfo formats exist (msvc's CodeView format or https://en.wikipedia.org/wiki/Stabs) so we could have chosen to generalize the flag name (`-{C,Z} debuginfo-version=dwarf-5` for example). While this would extend cleanly to support formats other than DWARF, there are some downsides to this design. Neither CodeView nor Stabs have specification or format versions so it's not clear what values would be supported beyond `dwarf-{2,3,4,5}` or `codeview`. We would also need to take care to ensure the name does not lead users to think they can pick a format other than one supported by the target. For instance, what would `--target x86_64-pc-windows-msvc -Cdebuginfo-version=dwarf-5` do? 2. What is the behavior when flag is used on targets that do not support DWARF? Currently, passing `-{C,Z} dwarf-version` on targets like `*-windows-msvc` does not do anything. It may be preferable to emit a warning alerting the user that the flag has no effect on the target platform. Alternatively, we could emit an error but this could be annoying since it would require the use of target specific RUSTFLAGS to use the flag correctly (and there isn't a way to target "any platform that uses DWARF" using cfgs). 3. Does the precompiled standard library potentially using a different version of DWARF a problem? I don't believe this is an issue as debuggers (and other such tools) already must deal with the possibility that an application uses different DWARF versions across its statically or dynamically linked libraries. ## Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those. No extensions per se, although future DWARF versions could be considered as such. At present, we validate the requested DWARF version is between 2 and 5 (inclusive) so new DWARF versions will not automatically be supported until the validation logic is adjusted. ## Summarize the major parts of the implementation and provide links into the code (or to PRs) - Targets define their preferred or default DWARF version: https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_target/src/spec/mod.rs#L2369 - We use the target default but this can be overriden by `-{C,Z} dwarf-version` https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L738 - The flag is validated https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L1253-L1258 - When debuginfo is generated, we tell LLVM to use the requested value or the target default https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_codegen_llvm/src/debuginfo/mod.rs#L106 ## Summarize existing test coverage of this feature - Test that we actually generate the appropriate DWARF version - https://github.com./rust-lang/rust/blob/master/tests/assembly/dwarf5.rs - https://github.com./rust-lang/rust/blob/master/tests/assembly/dwarf4.rs - Test that LTO with different DWARF versions picks the highest version - https://github.com./rust-lang/rust/blob/master/tests/assembly/dwarf-mixed-versions-lto.rs - Test DWARF versions 2-5 are valid while 0, 1 and 6 report an error - https://github.com./rust-lang/rust/blob/master/tests/ui/debuginfo/dwarf-versions.rs - Ensure LLVM does not report a warning when LTO'ing different DWARF versions together - https://github.com./rust-lang/rust/blob/master/tests/ui/lto/dwarf-mixed-versions-lto.rs ## Has a call-for-testing period been conducted? If so, what feedback was received? No call-for-testing has been conducted but Rust for Linux has been using this flag without issue. ## What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? All reported bugs have been resolved. ## Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization - Initial implementation in rust-lang#98350 by `@pcwalton` - Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in rust-lang#117962 by `@weihanglo.` - Refactoring & cleanups (rust-lang#135739), fix LLVM warning on LTO with different DWARF versions (rust-lang#136659) and argument validation (rust-lang#136746) by `@wesleywiser` ## What FIXMEs are still in the code for that feature and why is it ok to leave them there? No FIXMEs related to this feature. ## What static checks are done that are needed to prevent undefined behavior? This feature cannot cause undefined behavior. We ensure the DWARF version is one of the supported values [here](https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L1255-L1257). ## In what way does this feature interact with the reference/specification, and are those edits prepared? No changes to reference/spec, unstable rustc docs are moved to the stable book as part of the stabilization PR. ## Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. ## What other unstable features may be exposed by this feature? `-Zembed-source` requires use of DWARF 5 extensions but has its own feature gate. ## What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.? No support needed for rustdoc, clippy, rust-analyzer, rustfmt or rustup. Cargo could expose this as an option in build profiles but I would expect the decision as to what version should be used would be made for the entire crate graph at build time rather than by individual package authors. cc-rs has support for detecting the presence of `-{C,Z} dwarf-version` in `RUSTFLAGS` and providing the corresponding flag to Clang/gcc (rust-lang/cc-rs#1395). --- Closes rust-lang#103057

pnkfelix mentioned this issue Oct 14, 2022

Tracking Issue for defaulting to DWARF 5 format #75890

Closed

workingjubilee added the A-CLI Area: Command-line interface (CLI) to the compiler label Mar 5, 2023

ojeda mentioned this issue Feb 11, 2024

Rust unstable features needed for the kernel Rust-for-Linux/linux#2

Open

94 tasks

wesleywiser changed the title ~~provide way to users to opt into DWARF5 on stable Rust~~ Tracking issue for -Zdwarf-version Jan 19, 2025

wesleywiser mentioned this issue Jan 19, 2025

Clean up uses of the unstable dwarf_version option #135739

Merged

wesleywiser added the -Zdwarf-version Unstable option: set dwarf version label Feb 6, 2025

wesleywiser mentioned this issue Feb 6, 2025

Pick the max DWARF version when LTO'ing modules with different versions #136659

Merged

wesleywiser mentioned this issue Feb 8, 2025

Emit an error if -Zdwarf-version=1 is requested #136746

Merged

wesleywiser mentioned this issue Feb 12, 2025

Stabilize -Zdwarf-version as -Cdwarf-version #136926

Merged

bors closed this as completed in afa859f Apr 16, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for `-Zdwarf-version` #103057

Tracking issue for `-Zdwarf-version` #103057

pnkfelix commented Oct 14, 2022 •

edited by wesleywiser

Loading

thomcc commented Nov 10, 2022 •

edited

Loading

Wyvern commented Feb 3, 2023

fhanau commented Dec 24, 2024

Tracking issue for -Zdwarf-version #103057

Tracking issue for -Zdwarf-version #103057

Comments

pnkfelix commented Oct 14, 2022 • edited by wesleywiser Loading

About tracking issues

Steps

Unresolved Questions

Implementation history

thomcc commented Nov 10, 2022 • edited Loading

Wyvern commented Feb 3, 2023

fhanau commented Dec 24, 2024

Tracking issue for `-Zdwarf-version` #103057

Tracking issue for `-Zdwarf-version` #103057

pnkfelix commented Oct 14, 2022 •

edited by wesleywiser

Loading

thomcc commented Nov 10, 2022 •

edited

Loading