Cannot compile libcore #165
Comments
|
Hello. As far as I understood, you are maintainer of this project. I think this issue is related to #164. Do you have any ideas how to fix it? |
|
I've got what I think is the same error, but with a different message—probably because I'm using a no-assertion build of LLVM because of #151: I recompiled core with @_ZN4core3fmt12USIZE_MARKER17hdf4f8efe342c80b4E = local_unnamed_addr constant <{ i8*, [0 x i8] }> <{ i8* bitcast (i1 (i16*, %"fmt::Formatter"*) addrspace(1)* @_ZN4core3ops8function6FnOnce9call_once17hc62b6294245b6a49E to i8*), [0 x i8] zeroinitializer }>, align 1And here's the corresponding code in libcore: // This guarantees a single stable value for the function pointer associated with
// indices/counts in the formatting infrastructure.
//
// Note that a function defined as such would not be correct as functions are
// always tagged unnamed_addr with the current lowering to LLVM IR, so their
// address is not considered important to LLVM and as such the as_usize cast
// could have been miscompiled. In practice, we never call as_usize on non-usize
// containing data (as a matter of static generation of the formatting
// arguments), so this is merely an additional check.
//
// We primarily want to ensure that the function pointer at `USIZE_MARKER` has
// an address corresponding *only* to functions that also take `&usize` as their
// first argument. The read_volatile here ensures that we can safely ready out a
// usize from the passed reference and that this address does not point at a
// non-usize taking function.
#[unstable(feature = "fmt_internals", reason = "internal to format_args!", issue = "none")]
static USIZE_MARKER: fn(&usize, &mut Formatter<'_>) -> Result = |ptr, _| {
// SAFETY: ptr is a reference
let _v: usize = unsafe { crate::ptr::read_volatile(ptr) };
loop {}
};That flies way over my head, but it does seem like some sort of crazy unsafe crap that wouldn't work on a Harvard architecture. |
|
@Gaelan you're exactly right, this will be an address space bug that only affects Harvard architectures. @Logarithmus This bug is vey similar to #143, and will have the same fix. In summary, AVR functions are placed in address space There are two sources of address space bug - 1) when LLVM loses information during the middle end optimization pipeline, and 2) when Rust emits incorrect IR that has invalid casts from the get-go because there are places in Rustc that will assume all pointers are in address space This looks like an instance of (2). #143 is also an instance of (2).It is likely that both #165 and #143 originate from the same, unidentified piece of Rustc LLVM lowering logic that is specifying function pointer types in address space There are two solutions - 1) permanent fix to stop Rustc from losing address space information/making address space assumptions, and 2) hacky workaround to amend the In #143, we fixed it via method (2) - the hacky workaround by inserting a second cast (with |
|
/cc #169 |
|
Possible fix: rust-lang#73270 I have not verified it with the original reproduction though. |
The text was updated successfully, but these errors were encountered: