Double-word align _Unwind_Exception - #161368
Open
hsanzg wants to merge 1 commit into
Open
Conversation
rustbot
added
the
S-waiting-on-review
Collaborator
|
Thanks for the pull request, and welcome! The Rust Project has assigned @jieyouxu (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks. Please see the contribution instructions for more information. Why was this reviewer chosen?The reviewer was selected based on:
|
Member
|
r? libs |
rustbot
added
the
T-libs
tgross35
reviewed
Aug 20, 2026
Member
|
Cc @bjorn3 since this is your area of expertise |
bjorn3
approved these changes
Aug 20, 2026
Contributor
rust-bors
Bot
added
S-waiting-on-bors
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 20, 2026
Double-word align `_Unwind_Exception` The [Itanium C++ ABI spec](https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html) states that the `_Unwind_Exception` type must be double-word aligned (see Section 1.2). The missing alignment option does not seem to cause problems when a) using Rust's panic mechanism (because the exception object passed to `_Unwind_RaiseException` is [heap-allocated](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/library/panic_unwind/src/gcc.rs#L62) and thus double-word aligned by accident---although this is not guaranteed) or b) when linking against libgcc's unwinder. Most people don't need to unwind stacks themselves, so case (a) usually applies; and case (b) is the default for the `amd64-unknown-linux-gnu` target. Thus, misalignments seem unlikely to cause trouble in practice. However, I recently copied over some of the type definitions in `library/unwind` into a personal project, built `rustc` with `rust.llvm-libunwind = "system"`, and installed LLVM's `libunwind-24-dev`. Calling `_Unwind_RaiseException` with a thread-local `_Unwind_Exception` object led to a segfault due to the too-small default alignment. So `libunwind` seems to depend on the double-word alignment. N.B.: Both `libunwind` and `libgcc` have comments [1, 2] saying that the "double-word" alignment is a bit ambiguous when interpreted in a target-agnostic sense, and they both add `__attribute__((__aligned__))` to `_Unwind_Exception`, with no specific alignment value (the default is the maximum alignment of any integer type). Rust doesn't have such a "default" alignment, so I interpreted "double-word" in a target-dependent manner via `cfg_attr` + the `target_pointer_width` feature. \[1]: https://github.com/llvm/llvm-project/blob/196786fa5fe4225539678fc7904a383eca05374e/libunwind/include/unwind_itanium.h#L41 \[2]: https://github.com/gcc-mirror/gcc/blob/50a2eb56b9a350ecced4db4942e92d463dab8d8f/libgcc/unwind-generic.h#L106
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 20, 2026
Double-word align `_Unwind_Exception` The [Itanium C++ ABI spec](https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html) states that the `_Unwind_Exception` type must be double-word aligned (see Section 1.2). The missing alignment option does not seem to cause problems when a) using Rust's panic mechanism (because the exception object passed to `_Unwind_RaiseException` is [heap-allocated](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/library/panic_unwind/src/gcc.rs#L62) and thus double-word aligned by accident---although this is not guaranteed) or b) when linking against libgcc's unwinder. Most people don't need to unwind stacks themselves, so case (a) usually applies; and case (b) is the default for the `amd64-unknown-linux-gnu` target. Thus, misalignments seem unlikely to cause trouble in practice. However, I recently copied over some of the type definitions in `library/unwind` into a personal project, built `rustc` with `rust.llvm-libunwind = "system"`, and installed LLVM's `libunwind-24-dev`. Calling `_Unwind_RaiseException` with a thread-local `_Unwind_Exception` object led to a segfault due to the too-small default alignment. So `libunwind` seems to depend on the double-word alignment. N.B.: Both `libunwind` and `libgcc` have comments [1, 2] saying that the "double-word" alignment is a bit ambiguous when interpreted in a target-agnostic sense, and they both add `__attribute__((__aligned__))` to `_Unwind_Exception`, with no specific alignment value (the default is the maximum alignment of any integer type). Rust doesn't have such a "default" alignment, so I interpreted "double-word" in a target-dependent manner via `cfg_attr` + the `target_pointer_width` feature. \[1]: https://github.com/llvm/llvm-project/blob/196786fa5fe4225539678fc7904a383eca05374e/libunwind/include/unwind_itanium.h#L41 \[2]: https://github.com/gcc-mirror/gcc/blob/50a2eb56b9a350ecced4db4942e92d463dab8d8f/libgcc/unwind-generic.h#L106
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 20, 2026
Double-word align `_Unwind_Exception` The [Itanium C++ ABI spec](https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html) states that the `_Unwind_Exception` type must be double-word aligned (see Section 1.2). The missing alignment option does not seem to cause problems when a) using Rust's panic mechanism (because the exception object passed to `_Unwind_RaiseException` is [heap-allocated](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/library/panic_unwind/src/gcc.rs#L62) and thus double-word aligned by accident---although this is not guaranteed) or b) when linking against libgcc's unwinder. Most people don't need to unwind stacks themselves, so case (a) usually applies; and case (b) is the default for the `amd64-unknown-linux-gnu` target. Thus, misalignments seem unlikely to cause trouble in practice. However, I recently copied over some of the type definitions in `library/unwind` into a personal project, built `rustc` with `rust.llvm-libunwind = "system"`, and installed LLVM's `libunwind-24-dev`. Calling `_Unwind_RaiseException` with a thread-local `_Unwind_Exception` object led to a segfault due to the too-small default alignment. So `libunwind` seems to depend on the double-word alignment. N.B.: Both `libunwind` and `libgcc` have comments [1, 2] saying that the "double-word" alignment is a bit ambiguous when interpreted in a target-agnostic sense, and they both add `__attribute__((__aligned__))` to `_Unwind_Exception`, with no specific alignment value (the default is the maximum alignment of any integer type). Rust doesn't have such a "default" alignment, so I interpreted "double-word" in a target-dependent manner via `cfg_attr` + the `target_pointer_width` feature. \[1]: https://github.com/llvm/llvm-project/blob/196786fa5fe4225539678fc7904a383eca05374e/libunwind/include/unwind_itanium.h#L41 \[2]: https://github.com/gcc-mirror/gcc/blob/50a2eb56b9a350ecced4db4942e92d463dab8d8f/libgcc/unwind-generic.h#L106
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Aug 20, 2026
Double-word align `_Unwind_Exception` The [Itanium C++ ABI spec](https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html) states that the `_Unwind_Exception` type must be double-word aligned (see Section 1.2). The missing alignment option does not seem to cause problems when a) using Rust's panic mechanism (because the exception object passed to `_Unwind_RaiseException` is [heap-allocated](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/library/panic_unwind/src/gcc.rs#L62) and thus double-word aligned by accident---although this is not guaranteed) or b) when linking against libgcc's unwinder. Most people don't need to unwind stacks themselves, so case (a) usually applies; and case (b) is the default for the `amd64-unknown-linux-gnu` target. Thus, misalignments seem unlikely to cause trouble in practice. However, I recently copied over some of the type definitions in `library/unwind` into a personal project, built `rustc` with `rust.llvm-libunwind = "system"`, and installed LLVM's `libunwind-24-dev`. Calling `_Unwind_RaiseException` with a thread-local `_Unwind_Exception` object led to a segfault due to the too-small default alignment. So `libunwind` seems to depend on the double-word alignment. N.B.: Both `libunwind` and `libgcc` have comments [1, 2] saying that the "double-word" alignment is a bit ambiguous when interpreted in a target-agnostic sense, and they both add `__attribute__((__aligned__))` to `_Unwind_Exception`, with no specific alignment value (the default is the maximum alignment of any integer type). Rust doesn't have such a "default" alignment, so I interpreted "double-word" in a target-dependent manner via `cfg_attr` + the `target_pointer_width` feature. \[1]: https://github.com/llvm/llvm-project/blob/196786fa5fe4225539678fc7904a383eca05374e/libunwind/include/unwind_itanium.h#L41 \[2]: https://github.com/gcc-mirror/gcc/blob/50a2eb56b9a350ecced4db4942e92d463dab8d8f/libgcc/unwind-generic.h#L106
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 20, 2026
…uwer Rollup of 20 pull requests Successful merges: - #152617 (std: implement `sleep_until` for Fuchsia) - #158934 (diagnostics: fix `let x: vec![]` suggestion pointing into stdlib) - #161277 (bootstrap: Move all non-module items out of the crate root) - #161295 (std: don't panic on long-elapsed deadlines for `sleep_until`) - #161368 (Double-word align `_Unwind_Exception`) - #161370 (Uplift rustfmt macro formatting fix) - #161378 (`FlowSensitiveAnalysis` cleanups) - #158032 (Offload expose device selection) - #158855 (Add `desktop` method to `CommandExt`) - #161199 (Add regression test for non lifetime binders) - #161302 (Add regression test for inconsistent import resolution from issue 147208) - #161329 (Add regression tests for a few fixed issues with E-needs-test) - #161330 (Add regression test for nested RPIT not an iterator ICE) - #161351 (Cleanup: Move impl of `#[rustc_dump_object_lifetime_defaults]`) - #161355 (Add file path to some archive build errors) - #161373 (Allow running EC2 jobs locally) - #161393 (Configure LLM policy URL for triagebot) - #161409 (Add back `tests/rustdoc-gui/notable-trait.goml` test) - #161410 (Fix rustdoc remapping `documentation` scope documentation) - #161415 (Update expect messages in path docs to better follow guidelines)
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Aug 21, 2026
Double-word align `_Unwind_Exception` The [Itanium C++ ABI spec](https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html) states that the `_Unwind_Exception` type must be double-word aligned (see Section 1.2). The missing alignment option does not seem to cause problems when a) using Rust's panic mechanism (because the exception object passed to `_Unwind_RaiseException` is [heap-allocated](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/library/panic_unwind/src/gcc.rs#L62) and thus double-word aligned by accident---although this is not guaranteed) or b) when linking against libgcc's unwinder. Most people don't need to unwind stacks themselves, so case (a) usually applies; and case (b) is the default for the `amd64-unknown-linux-gnu` target. Thus, misalignments seem unlikely to cause trouble in practice. However, I recently copied over some of the type definitions in `library/unwind` into a personal project, built `rustc` with `rust.llvm-libunwind = "system"`, and installed LLVM's `libunwind-24-dev`. Calling `_Unwind_RaiseException` with a thread-local `_Unwind_Exception` object led to a segfault due to the too-small default alignment. So `libunwind` seems to depend on the double-word alignment. N.B.: Both `libunwind` and `libgcc` have comments [1, 2] saying that the "double-word" alignment is a bit ambiguous when interpreted in a target-agnostic sense, and they both add `__attribute__((__aligned__))` to `_Unwind_Exception`, with no specific alignment value (the default is the maximum alignment of any integer type). Rust doesn't have such a "default" alignment, so I interpreted "double-word" in a target-dependent manner via `cfg_attr` + the `target_pointer_width` feature. \[1]: https://github.com/llvm/llvm-project/blob/196786fa5fe4225539678fc7904a383eca05374e/libunwind/include/unwind_itanium.h#L41 \[2]: https://github.com/gcc-mirror/gcc/blob/50a2eb56b9a350ecced4db4942e92d463dab8d8f/libgcc/unwind-generic.h#L106
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Itanium C++ ABI spec states that the
_Unwind_Exceptiontype must be double-word aligned (see Section 1.2). The missing alignment option does not seem to cause problems when a) using Rust's panic mechanism (because the exception object passed to_Unwind_RaiseExceptionis heap-allocated and thus double-word aligned by accident---although this is not guaranteed) or b) when linking against libgcc's unwinder.Most people don't need to unwind stacks themselves, so case (a) usually applies; and case (b) is the default for the
amd64-unknown-linux-gnutarget. Thus, misalignments seem unlikely to cause trouble in practice. However, I recently copied over some of the type definitions inlibrary/unwindinto a personal project, builtrustcwithrust.llvm-libunwind = "system", and installed LLVM'slibunwind-24-dev. Calling_Unwind_RaiseExceptionwith a thread-local_Unwind_Exceptionobject led to a segfault due to the too-small default alignment. Solibunwindseems to depend on the double-word alignment.N.B.: Both
libunwindandlibgcchave comments [1, 2] saying that the "double-word" alignment is a bit ambiguous when interpreted in a target-agnostic sense, and they both add__attribute__((__aligned__))to_Unwind_Exception, with no specific alignment value (the default is the maximum alignment of any integer type). Rust doesn't have such a "default" alignment, so I interpreted "double-word" in a target-dependent manner viacfg_attr+ thetarget_pointer_widthfeature.[1]: https://github.com/llvm/llvm-project/blob/196786fa5fe4225539678fc7904a383eca05374e/libunwind/include/unwind_itanium.h#L41
[2]: https://github.com/gcc-mirror/gcc/blob/50a2eb56b9a350ecced4db4942e92d463dab8d8f/libgcc/unwind-generic.h#L106