-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make LLVMRustGetOrInsertGlobal
always return a GlobalVariable
#91070
Conversation
`Module::getOrInsertGlobal` returns a `Constant*`, which is a super class of `GlobalVariable`, but if the given type doesn't match an existing declaration, it returns a bitcast of that global instead. This causes UB when we pass that to `LLVMGetVisibility` which unconditionally casts the opaque argument to a `GlobalValue*`. Instead, we can do our own get-or-insert without worrying whether existing types match exactly. It's not relevant when we're just trying to get/set the linkage and visibility, and if types are needed we can bitcast or error nicely from `rustc_codegen_llvm` instead.
(rust-highfive has picked a reviewer for you, use r? to override) |
cc @datdenkikniet @haraldh -- if you could confirm that this fixes your bugs, that would be great. I'll start a build: @bors try |
⌛ Trying commit 023cc96 with merge 04339b3fab9c798bce7fed137e7f5ac81ab52509... |
cc @hellow554 was also testing those bugs. |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Ah, actually, I do have a concern about what would happen with the code of the following shape (i.e. actual uses of the differently typed globals exist): pub mod before {
extern "C" {
pub static GLOBAL1: [u8; 1];
}
pub unsafe fn do_something_with_array() -> u8 {
GLOBAL1[0]
}
}
pub mod inner {
extern "C" {
pub static GLOBAL1: u8;
}
pub unsafe fn call() -> u8 {
GLOBAL1 + 42
}
} can we add a test like that too? As I was busy coming up with the test case I built a compiler with this change, and indeed this case is problematic, building it with the following flags produces:
@bors r- for now |
Are you sure your edit: it's also fine with the try build |
Co-authored-by: Simonas Kazlauskas <git@kazlauskas.me>
@nagisa I added your test variant. |
/me facepalms. @bors r+ Thanks! |
📌 Commit 3b2cfa5 has been approved by |
This comment has been minimized.
This comment has been minimized.
Moved the tests to appease tidy. @bors r=nagisa |
📌 Commit 3aa1954 has been approved by |
…askrgr Rollup of 4 pull requests Successful merges: - rust-lang#91008 (Adds IEEE 754-2019 minimun and maximum functions for f32/f64) - rust-lang#91070 (Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable`) - rust-lang#91097 (Add spaces in opaque `impl Trait` with more than one trait) - rust-lang#91098 (Don't suggest certain fixups (`.field`, `.await`, etc) when reporting errors while matching on arrays ) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
A little late to the party perhaps, but this PR does indeed seem to fix the issues we faced in #87933 It's slightly difficult to tell because the error was spurious, but I've cleaned/built about 10 times now and it hasn't produced an error once, which it did do relatively consistently before these changes. |
Is it too late to get this in 1.57? |
It is very late for 1.57, but possibly not too late -- @Mark-Simulacrum what do you think? |
Given that it is fixing a relatively longstanding regression I would personally prefer this to ride the 🚆. |
If it's nominated/accepted by beta backport quite soon (next ~72 hours), we can get it in, but not otherwise. I have no strong opinion or sense of the exact possibility for problems caused by this patch, though. |
I'm OK with @nagisa's opinion to let it wait through the normal release process, but I might still backport in Fedora for its bug. |
Module::getOrInsertGlobal
returns aConstant*
, which is a superclass of
GlobalVariable
, but if the given type doesn't match anexisting declaration, it returns a bitcast of that global instead.
This causes UB when we pass that to
LLVMGetVisibility
whichunconditionally casts the opaque argument to a
GlobalValue*
.Instead, we can do our own get-or-insert without worrying whether
existing types match exactly. It's not relevant when we're just trying
to get/set the linkage and visibility, and if types are needed we can
bitcast or error nicely from
rustc_codegen_llvm
instead.Fixes #91050, fixes #87933, fixes #87813.