Design meeting: resolve ABI issues around target-feature #235
Labels
Comments
RalfJung
changed the title
This was referenced Nov 11, 2023
|
I don't know the intended permissions, but the hackmd isn't publicly visible |
|
Sorry for that -- fixed. |
With the rust-lang website down... can you remind us of the time and place of these meetings? |
|
I did find the calendar link on this page but I can't view the calendar, it requires logging with a Google account and I don't have one (nor do I want to create one). |
|
|
Cross-posting from #116584... We discussed this question in the T-lang design meeting on 2023-12-20. The consensus was generally in favor of fixing this, and we were interested in seeing more work in this direction. While we considered various ways that this could be fixed, we were supportive of finding the most minimal, simplest way to fix this as the first step, assuming that such an approach proves to be feasible. We'll need to see at least the results of a crater run and further analysis to confirm that feasibility. We appreciate @RalfJung and all the others who have been investing time to push this forward. |
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Jul 14, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Jul 15, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Jul 16, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Jul 16, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Jul 22, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Jul 22, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Jul 22, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Jul 24, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Jul 28, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Jul 28, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 1, 2024
Emit error when calling/declaring functions with unavailable vectors. On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant. r? RalfJung
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Aug 12, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Aug 14, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
veluca93
added a commit
to veluca93/rust
that referenced
this issue
Aug 14, 2024
On some architectures, vector types may have a different ABI when relevant target features are enabled. As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it an error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant.
|
We finally have an implementation of this in rust-lang/rust#127731. :) Would be nice to get some feedback from the team on whether that's a good direction to proceed in. |
This was referenced Sep 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Target features generally control which instructions codegen may use during the final step of generating assembly, but some of them also affect how arguments and return values are passed across function call boundaries.
This means that in general, code compiled with different target features is not ABI-compatible and cannot be linked with each other.
In particular, since the standard library is shipped in binary form pre-built for the default set of target features, enabling/disabling particular features means that calling standard library methods suddenly causes Undefined Behavior.
That's a soundness bug that we clearly should tackle.
Background reading
Design meeting document: https://hackmd.io/e4bYAMh2RWG2yKZHivmF9Q
About this issue
This issue corresponds to a lang-team design meeting proposal. It corresponds to a possible topic of discussion that may be scheduled for deeper discussion during one of our design meetings.
The text was updated successfully, but these errors were encountered: