Add support for setting -gdwarf-{version} based on RUSTFLAGS by wesleywiser · Pull Request #1395 · rust-lang/cc-rs (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation6 Commits1 Checks73 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

Detect if -Zdwarf-version (which will probably be stabilized soon as -Cdwarf-version) was passed in RUSTFLAGS and set the corresponding Clang/GCC option to the same value.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks LGTM!

cc @madsmtm for a double checkq

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine after parsing. I verified that the semantics are the same.

Detect if -Zdwarf-version (which will probably be stabilized soon as -Cdwarf-version) was passed in RUSTFLAGS and set the corresponding Clang/GCC option to the same value.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

For posterity, I'll note that I considered if it would make sense to restrict even further (e.g. only accept 2, 3, 4 or 5), but then again, Clang and GCC support more versions than rustc (and that will probably be true for the foreseeable future), and the compiler driver will just error if it doesn't support the flag anyhow. So it's probably better to treat these as integers, and be "future compatible" with a hypothetical DWARF 6.

This was referenced

Feb 14, 2025

bors added a commit to rust-lang-ci/rust that referenced this pull request

Feb 15, 2025

bors added a commit to rust-lang-ci/rust that referenced this pull request

Feb 15, 2025

github-merge-queue bot pushed a commit to rust-lang/cargo that referenced this pull request

Feb 28, 2025

…15245)

What does this PR try to resolve?

GitHub Runner Images 20250224.5.0+ ship Windows 11 SDK 10.0.26100+ compared to the previous Windows 11 SDK 10.0.22621, which bumped the UCRT headers. The new UCRT headers use SSE2 types. However, cc versions <= 1.2.15 emit /arch:IA32 for x86 Windows targets for clang-cl, which causes compilation errors since clang-cl can't find SSE2 types without /arch:SSE2 specified (or defaulted). (Note that MSVC at the time of writing silently accepts and emits instruments for code using SSE2 types, as opposed to clang-cl hard error-ing).

cc 1.2.16 contains a fix for this problem, rust-lang/cc-rs#1425, to correctly emit /arch:SSE2 instead of /arch:IA32 to enable clang-cl to find the SSE2 types. However, cargo's cc currently is still on 1.2.13.

To fix this for rust-lang/rust CI, we need to bump anything that transitively relies on cc and tries to use clang-cl on x86 Windows targets to compile any C/C++ code that transitively use functions or types that require SSE2 types, such as <wchar.h>.

How should we test and review this PR?

The fix was initially intended for rustc_{codegen_ssa,llvm} cc, and based on testing in rust-lang/rust#137724, I was able to successfully build rustc_{codegen_ssa,llvm} with a forked cc based on 1.2.15 which contains the fix from rust-lang/cc-rs#1425. Note that in the same PR, while the compiler build succeeded, the build of cargo itself failed since it transitively used a cc without the fix to build curl-sys[^dep-chain], which failed as one might expect (curl-sys tries to build C code that uses <wchar.h> which runs into the same problem). Hence, this PR is opened to bump cargo's cc to a cc version containing the fix.

Additional information

This x86 Windows CI problem is:

• Discussed in https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/spurious.20.28.3F.29.20i686.20msvc.20errors.
• Tracked by rust-lang/rust#137733.

cc changelog between 1.2.13 and 1.2.16

[^dep-chain]: I think the dep chain is something like git2 -> libgit2-sys -> curl -> curl-sys?

jieyouxu added a commit to jieyouxu/rust that referenced this pull request

Feb 28, 2025

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Feb 28, 2025

Zalathar added a commit to Zalathar/rust that referenced this pull request

Apr 16, 2025

…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.

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

bors added a commit to rust-lang-ci/rust that referenced this pull request

Apr 16, 2025

… 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.

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

github-actions bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request

Apr 17, 2025

…henkov

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/rust#98350 and was not deemed large enough to require additional process.

The tracking issue for this feature is #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/rust#98350 by @pcwalton
• Stop emitting .debug_pubnames and .debug_pubtypes when using DWARF 5 in rust-lang/rust#117962 by @weihanglo.
• Refactoring & cleanups (#135739), fix LLVM warning on LTO with different DWARF versions (#136659) and argument validation (#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.

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 #103057

github-actions bot pushed a commit to rust-lang/miri that referenced this pull request

Apr 17, 2025

…henkov

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/rust#98350 and was not deemed large enough to require additional process.

The tracking issue for this feature is #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/rust#98350 by @pcwalton
• Stop emitting .debug_pubnames and .debug_pubtypes when using DWARF 5 in rust-lang/rust#117962 by @weihanglo.
• Refactoring & cleanups (#135739), fix LLVM warning on LTO with different DWARF versions (#136659) and argument validation (#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.

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 #103057

lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request

Apr 28, 2025

…henkov

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/rust#98350 and was not deemed large enough to require additional process.

The tracking issue for this feature is #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/rust#98350 by @pcwalton
• Stop emitting .debug_pubnames and .debug_pubtypes when using DWARF 5 in rust-lang/rust#117962 by @weihanglo.
• Refactoring & cleanups (#135739), fix LLVM warning on LTO with different DWARF versions (#136659) and argument validation (#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.

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 #103057