fix: stop emitting `.debug_pubnames` and `.debug_pubtypes` by weihanglo · Pull Request #117962 · rust-lang/rust (original) (raw)

r? @cuviper

(rustbot has picked a reviewer for you, use r? to override)

rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

labels

Nov 16, 2023

This comment has been minimized.

weihanglo changed the title~~[EXPERIMENT] feat: -Zdebug-name-table to turn debug pub sections off~~ [EXPERIMENT] fix: stop emitting .debug_pubnames and .debug_pubtypes

Nov 17, 2023

This comment has been minimized.

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

Nov 17, 2023

[EXPERIMENT] fix: stop emitting .debug_pubnames and .debug_pubtypes

DO NOT MERGE

A continuation of rust-lang#94181. Fixes rust-lang#48762 MCP can be found in <rust-lang/compiler-team#688>.

.debug_pubnames and .debug_pubtypes are poorly designed and people seldom use them. However, they take a considerable portion of size in the final binary. This tells LLVM stop emitting those sections on DWARFv4 or lower. DWARFv5 use .debug_names which is more concise in size and performant for name lookup.

This comment has been minimized.

☀️ Try build successful - checks-actions
Build commit: 5432eb3 (5432eb3ad2dc081d86089b9ba74f66e9d21ab01d)

This comment has been minimized.

Finished benchmarking commit (5432eb3): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.2%	[-4.9%, -0.5%]	20
Improvements ✅ (secondary)	-1.8%	[-3.4%, -0.4%]	56
All ❌✅ (primary)	-2.2%	[-4.9%, -0.5%]	20

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean	range	count
Regressions ❌ (primary)	0.9%	[0.9%, 0.9%]	1
Regressions ❌ (secondary)	2.4%	[0.9%, 4.0%]	5
Improvements ✅ (primary)	-2.1%	[-4.1%, -0.6%]	6
Improvements ✅ (secondary)	-2.5%	[-2.5%, -2.5%]	1
All ❌✅ (primary)	-1.7%	[-4.1%, 0.9%]	7

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.7%	[-2.7%, -0.8%]	7
Improvements ✅ (secondary)	-1.4%	[-1.7%, -0.9%]	14
All ❌✅ (primary)	-1.7%	[-2.7%, -0.8%]	7

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-9.5%	[-22.2%, -0.3%]	112
Improvements ✅ (secondary)	-14.1%	[-28.4%, -0.0%]	104
All ❌✅ (primary)	-9.5%	[-22.2%, -0.3%]	112

Bootstrap: 676.352s -> 676.511s (0.02%)
Artifact size: 313.63 MiB -> 311.68 MiB (-0.62%)

Great results! Is this only a win for DWARFv4 and lower? What determines the DWARF version being used?

@nnethercote -Zdwarf-version is still unstable. For most platforms rustc defaults to DWARFv4.

I've checked the binary size of v5 locally with .debug_names emitted. It was even better than the current result, marginally though.

I am looking forward to DWARFv5 being default :)

weihanglo changed the title~~[EXPERIMENT] fix: stop emitting .debug_pubnames and .debug_pubtypes~~ fix: stop emitting .debug_pubnames and .debug_pubtypes

Nov 27, 2023

r? wesleywiser

This is ready for review, though I understand 10-day period of MCP rust-lang/compiler-team#688 hasn't yet passed.

The first commit demonstrates that rustc did emit name tables for both dwarf v4 and v5.
The second commit changes the behavior and verifies v4 stop emitting those tables.

Finished benchmarking commit (e2a3c9b): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.1%	[-5.2%, -0.3%]	24
Improvements ✅ (secondary)	-1.6%	[-3.1%, -0.2%]	61
All ❌✅ (primary)	-2.1%	[-5.2%, -0.3%]	24

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.6%	[-0.6%, -0.6%]	1
Improvements ✅ (secondary)	-2.3%	[-2.3%, -2.3%]	1
All ❌✅ (primary)	-0.6%	[-0.6%, -0.6%]	1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	6.5%	[6.5%, 6.5%]	1
Improvements ✅ (primary)	-1.6%	[-3.0%, -0.7%]	11
Improvements ✅ (secondary)	-1.4%	[-1.9%, -1.0%]	10
All ❌✅ (primary)	-1.6%	[-3.0%, -0.7%]	11

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-9.6%	[-22.2%, -0.3%]	112
Improvements ✅ (secondary)	-14.1%	[-28.4%, -0.0%]	104
All ❌✅ (primary)	-9.6%	[-22.2%, -0.3%]	112

Bootstrap: 672.051s -> 672.519s (0.07%)
Artifact size: 314.25 MiB -> 312.30 MiB (-0.62%)

fbq pushed a commit to Rust-for-Linux/linux that referenced this pull request

Feb 17, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

Required changes

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Other changes

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

In addition, the rustc_codegen_gcc backend now does not emit the .eh_frame section when compiling under -Cpanic=abort [6], thus removing the need for the patch in the CI to compile the kernel [7]. Moreover, it also now emits the .comment section too [6].

`alloc` upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended.

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1760-2024-02-08 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: #2 [3] Link: rust-lang/compiler-team#688 [4] Link: rust-lang/rust#117962 [5] Link: rust-lang/rust#118068 [6] Link: https://github.com/Rust-for-Linux/ci-rustc_codegen_gcc [7] Signed-off-by: Miguel Ojeda ojeda@kernel.org Link: https://lore.kernel.org/r/20240217002638.57373-2-ojeda@kernel.org

fbq pushed a commit to Rust-for-Linux/linux that referenced this pull request

Feb 19, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

Required changes

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Other changes

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

`alloc` upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

ojeda added a commit to Rust-for-Linux/linux that referenced this pull request

Feb 29, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

Required changes

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Other changes

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

`alloc` upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1760-2024-02-08 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: #2 [3] Link: rust-lang/compiler-team#688 [4] Link: rust-lang/rust#117962 [5] Link: rust-lang/rust#118068 [6] Link: https://github.com/Rust-for-Linux/ci-rustc_codegen_gcc [7] Tested-by: Boqun Feng boqun.feng@gmail.com Reviewed-by: Alice Ryhl aliceryhl@google.com Link: https://lore.kernel.org/r/20240217002638.57373-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda ojeda@kernel.org

bertschingert pushed a commit to bertschingert/bcachefs that referenced this pull request

Mar 9, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

Required changes

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Other changes

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

`alloc` upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1760-2024-02-08 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux/linux#2 [3] Link: rust-lang/compiler-team#688 [4] Link: rust-lang/rust#117962 [5] Link: rust-lang/rust#118068 [6] Link: https://github.com/Rust-for-Linux/ci-rustc_codegen_gcc [7] Tested-by: Boqun Feng boqun.feng@gmail.com Reviewed-by: Alice Ryhl aliceryhl@google.com Link: https://lore.kernel.org/r/20240217002638.57373-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda ojeda@kernel.org

bertschingert pushed a commit to bertschingert/bcachefs that referenced this pull request

Mar 9, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

Required changes

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Other changes

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

`alloc` upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

y86-dev pushed a commit to y86-dev/linux that referenced this pull request

Mar 10, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1760-2024-02-08 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux#2 [3] Link: rust-lang/compiler-team#688 [4] Link: rust-lang/rust#117962 [5] Link: rust-lang/rust#118068 [6] Link: https://github.com/Rust-for-Linux/ci-rustc_codegen_gcc [7] Tested-by: Boqun Feng boqun.feng@gmail.com Reviewed-by: Alice Ryhl aliceryhl@google.com Link: https://lore.kernel.org/r/20240217002638.57373-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda ojeda@kernel.org

bertschingert pushed a commit to bertschingert/bcachefs that referenced this pull request

Mar 12, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

Required changes

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Other changes

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

`alloc` upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

jannau pushed a commit to jannau/linux that referenced this pull request

Mar 25, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

Unstable features

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

Required changes

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Other changes

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

`alloc` upgrade and reviewing

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1760-2024-02-08 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux#2 [3] Link: rust-lang/compiler-team#688 [4] Link: rust-lang/rust#117962 [5] Link: rust-lang/rust#118068 [6] Link: https://github.com/Rust-for-Linux/ci-rustc_codegen_gcc [7] Tested-by: Boqun Feng boqun.feng@gmail.com Reviewed-by: Alice Ryhl aliceryhl@google.com Link: https://lore.kernel.org/r/20240217002638.57373-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda ojeda@kernel.org

jannau pushed a commit to jannau/linux that referenced this pull request

Apr 8, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1760-2024-02-08 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux#2 [3] Link: rust-lang/compiler-team#688 [4] Link: rust-lang/rust#117962 [5] Link: rust-lang/rust#118068 [6] Link: https://github.com/Rust-for-Linux/ci-rustc_codegen_gcc [7] Tested-by: Boqun Feng boqun.feng@gmail.com Reviewed-by: Alice Ryhl aliceryhl@google.com Link: https://lore.kernel.org/r/20240217002638.57373-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda ojeda@kernel.org

herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request

Apr 27, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request

Apr 27, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request

May 2, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

asahilina pushed a commit to AsahiLinux/linux that referenced this pull request

May 10, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1760-2024-02-08 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux#2 [3] Link: rust-lang/compiler-team#688 [4] Link: rust-lang/rust#117962 [5] Link: rust-lang/rust#118068 [6] Link: https://github.com/Rust-for-Linux/ci-rustc_codegen_gcc [7] Tested-by: Boqun Feng boqun.feng@gmail.com Reviewed-by: Alice Ryhl aliceryhl@google.com Link: https://lore.kernel.org/r/20240217002638.57373-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda ojeda@kernel.org

jannau pushed a commit to AsahiLinux/linux that referenced this pull request

May 22, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1760-2024-02-08 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux#2 [3] Link: rust-lang/compiler-team#688 [4] Link: rust-lang/rust#117962 [5] Link: rust-lang/rust#118068 [6] Link: https://github.com/Rust-for-Linux/ci-rustc_codegen_gcc [7] Tested-by: Boqun Feng boqun.feng@gmail.com Reviewed-by: Alice Ryhl aliceryhl@google.com Link: https://lore.kernel.org/r/20240217002638.57373-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda ojeda@kernel.org

herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request

May 27, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

herrnst pushed a commit to herrnst/linux-asahi that referenced this pull request

May 30, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

john-cabaj pushed a commit to UbuntuAsahi/linux that referenced this pull request

May 31, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1760-2024-02-08 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux#2 [3] Link: rust-lang/compiler-team#688 [4] Link: rust-lang/rust#117962 [5] Link: rust-lang/rust#118068 [6] Link: https://github.com/Rust-for-Linux/ci-rustc_codegen_gcc [7] Tested-by: Boqun Feng boqun.feng@gmail.com Reviewed-by: Alice Ryhl aliceryhl@google.com Link: https://lore.kernel.org/r/20240217002638.57373-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda ojeda@kernel.org (cherry picked from commit 6092708 https://github.com/AsahiLinux/linux) Signed-off-by: John Cabaj john.cabaj@canonical.com

john-cabaj pushed a commit to UbuntuAsahi/linux that referenced this pull request

Jun 17, 2024

This is the next upgrade to the Rust toolchain, from 1.75.0 to 1.76.0 (i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4 ("rust: upgrade to Rust 1.68.2").

No unstable features that we use were stabilized in Rust 1.76.0.

The only unstable features allowed to be used outside the kernel crate are still new_uninit,offset_of, though other code to be upstreamed may increase the list.

Please see [3] for details.

rustc (and others) now warns when it cannot connect to the Make jobserver, thus mark those invocations as recursive as needed. Please see the previous commit for details.

Rust 1.76.0 does not emit the .debug_pub{names,types} sections anymore for DWARFv4 [4][5]. For instance, in the uncompressed debug info case, this debug information took:

samples/rust/rust_minimal.o   ~64 KiB (~18% of total object size)
rust/kernel.o                 ~92 KiB (~15%)
rust/core.o                  ~114 KiB ( ~5%)

In the compressed debug info (zlib) case:

samples/rust/rust_minimal.o   ~11 KiB (~6%)
rust/kernel.o                 ~17 KiB (~5%)
rust/core.o                   ~21 KiB (~1.5%)

The vast majority of changes are due to our alloc fork being upgraded at once.

Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions.

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
    cut -d/ -f3- |
    grep -Fv README.md |
    xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1760-2024-02-08 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: Rust-for-Linux#2 [3] Link: rust-lang/compiler-team#688 [4] Link: rust-lang/rust#117962 [5] Link: rust-lang/rust#118068 [6] Link: https://github.com/Rust-for-Linux/ci-rustc_codegen_gcc [7] Tested-by: Boqun Feng boqun.feng@gmail.com Reviewed-by: Alice Ryhl aliceryhl@google.com Link: https://lore.kernel.org/r/20240217002638.57373-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda ojeda@kernel.org (cherry picked from commit 6092708 https://github.com/AsahiLinux/linux) Signed-off-by: John Cabaj john.cabaj@canonical.com

This was referenced

Feb 12, 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:

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?
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).
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

`-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:

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?
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).
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.

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.

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

`-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:

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?
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).
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.

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.

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

`-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:

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?
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).
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.

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.

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

`-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:

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?
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).
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.

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.

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

fix: stop emitting .debug_pubnames and .debug_pubtypes by weihanglo · Pull Request #117962 · rust-lang/rust (original) (raw)

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

DO NOT MERGE

This comment has been minimized.

This comment has been minimized.

Overall result: ✅ improvements - no action needed

Overall result: ✅ improvements - no action needed

Unstable features

Required changes

Other changes

alloc upgrade and reviewing

Unstable features

Required changes

Other changes

alloc upgrade and reviewing

Unstable features

Required changes

Other changes

alloc upgrade and reviewing

Unstable features

Required changes

Other changes

alloc upgrade and reviewing

Unstable features

Required changes

Other changes

alloc upgrade and reviewing

Unstable features

Required changes

Other changes

alloc upgrade and reviewing

Unstable features

Required changes

Other changes

alloc upgrade and reviewing

-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?

What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.

Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those.

Summarize the major parts of the implementation and provide links into the code (or to PRs)

Summarize existing test coverage of this feature

Has a call-for-testing period been conducted? If so, what feedback was received?

What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?

Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization

What FIXMEs are still in the code for that feature and why is it ok to leave them there?

What static checks are done that are needed to prevent undefined behavior?

In what way does this feature interact with the reference/specification, and are those edits prepared?

Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?

What other unstable features may be exposed by this feature?

What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.?

-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?

What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.

Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those.

Summarize the major parts of the implementation and provide links into the code (or to PRs)

Summarize existing test coverage of this feature

Has a call-for-testing period been conducted? If so, what feedback was received?

What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?

Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization

What FIXMEs are still in the code for that feature and why is it ok to leave them there?

What static checks are done that are needed to prevent undefined behavior?

In what way does this feature interact with the reference/specification, and are those edits prepared?

Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?

What other unstable features may be exposed by this feature?

What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.?

-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?

What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.

Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those.

Summarize the major parts of the implementation and provide links into the code (or to PRs)

Summarize existing test coverage of this feature

Has a call-for-testing period been conducted? If so, what feedback was received?

What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?

Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization

What FIXMEs are still in the code for that feature and why is it ok to leave them there?

What static checks are done that are needed to prevent undefined behavior?

In what way does this feature interact with the reference/specification, and are those edits prepared?

Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?

fix: stop emitting `.debug_pubnames` and `.debug_pubtypes` by weihanglo · Pull Request #117962 · rust-lang/rust (original) (raw)

`alloc` upgrade and reviewing

`alloc` upgrade and reviewing

`alloc` upgrade and reviewing

`alloc` upgrade and reviewing

`alloc` upgrade and reviewing

`alloc` upgrade and reviewing

`alloc` upgrade and reviewing

`-Zdwarf-version` stabilization report

`-Zdwarf-version` stabilization report

`-Zdwarf-version` stabilization report

`-Zdwarf-version` stabilization report

`-Zdwarf-version` stabilization report