Alignment of u64/i64 etc.

[DeltaF1]

I know that this is part of a much lower layer than this crate but I want to find where the alignment requirements for 64-bit integers are defined for the armv6k platform. I initially thought that u64s would be aligned to their size, but the documentation I can find on ARMv6 ^{1 2} suggests the alignment should only be 4-bytes. Unfortunately Rust believes that u64 is 8-byte aligned for this platform so I'd like to find a way to correct that. Does anybody know where I should look for that? libctru? rustc? I got lost trying to figure out how the min_align_of intrinsic is actually implemented in rustc.

Context

I've been getting back into generating IPC bindings, and noticed that some IPC calls (example) have u64 parameters which are not aligned to an 8-byte boundary. It would be very convenient if I could just put the u64s into structs as they are in the IPC buffer without worrying about aligned pointer issues on Rust's end and needing to use repr(packed).

Footnotes

1. https://developer.apple.com/documentation/xcode/writing-armv6-code-for-ios ↩

2. https://developer.arm.com/documentation/ddi0419/c/Application-Level-Architecture/Application-Level-Programmers--Model/ARM-processor-data-types-and-arithmetic ↩

[FenrirWolf]

I think you might have misread the chart you linked, as u64/i64 are equivalent to (unsigned) long long int and those types are specified to have an 8-byte alignment. You can confirm this yourself by building C program with devkitARM using __alignof__ on a long long int, and it will report that the variable has an alignment of 8. So Rust is already doing the right thing here and we absolutely wouldn't want to change that, and I'm pretty sure that you're stuck using #[repr(packed)] when interfacing with those kind of APIs.

But for future reference, this file is where the 3DS target spec is implemented in rustc, with the data_layout field in particular being where things like integer size and alignment are specified. This stackoverflow comment has more info about how to actually parse the information in that field.

[DeltaF1]

Ah okay, I see part of my confusion. I was only looking at the top of the Apple article where they say "Data types larger than 4 bytes are 4-byte aligned." Maybe these are exceptions for the Apple ABI specifically? After your comment I took another look and found the "Procedure Call Standard" (it has the same information in the table further down that page) which as you say specifies them to be 8-byte aligned. I guess I got hung up on the specifics of the hardware and not ABI compatibility.

For future reference...

Thanks for the links! That field and its parsing code is dense, the stackoverflow link was super helpful.

[Jhynjhiruu]

u64/i64 are definitely supposed to be 64-bit aligned - ctru-rs was plagued by a nasty crash related to thread-local storage for ages (#124) which happened because a u64 deep in the HashMap implementation was only aligned to 32 bits due to a difference in how LLVM and GCC implemented the ELF spec.

[DeltaF1]

Yeah I actually opened that issue :) The crash wasn't from a CPU alignment fault though, it was from the Rust library checking the alignment itself because u64 is defined by Rust to be 8-byte aligned. If Rust defined u64 as 4-byte aligned then that check would have passed. I've done some basic testing and I only get a fault when when the access is less aligned than 4 bytes, but I definitely could be missing something important. I found this manual for ARMv6 and it seems like double-word accesses are fine if word-aligned but it's dependent upon the mode the processor is in.

[Jhynjhiruu]

Oh, sorry! I completely skipped that it was you that opened the issue.
I did some investigation into it and I do think I remember it being because of alignment - compiling in release mode with the checks disabled still resulted in a crash.
You could probably check fairly easily though, since we build std from source, so changing the definition manually to set the alignment to 32 should be doable.

[DeltaF1]

Oh huh, I thought the TLS problem was just happening on debug. This is the code I was using to test earlier which worked just fine (it is UB but it appears to be doing an unaligned read and write with no issue). If I change the padding to be u8s or u16s then it crashes with an alignment fault since now the fields are aligned to less than 4-bytes.

#[repr(C, packed)]
struct unaligned {
    _padding1: u32,
    field1: u64,
    _padding2: u32,
    field2: u64,
    _padding3: u32,
    field3: u64,
}

fn main() {
    let mut a = unaligned {
        _padding1: 0,
        field1: 0x1234abcd5678ef90,
        _padding2: 0,
        field2: 0xa5a5a5a5a5a5a5a5,
        _padding3: 0,
        field3: 0xf0f0f0f0f0f0f0f0,
    };
    let ptrs = [
        std::ptr::addr_of_mut!(a.field1),
        std::ptr::addr_of_mut!(a.field2),
        std::ptr::addr_of_mut!(a.field3),
    ];
    unsafe {
        for (i, ptr) in ptrs.iter().enumerate() {
            println!("Writing to ptr {:?}", ptr);
            ptr.write_volatile(i.try_into().unwrap());
            println!("Reading from ptr {:?}", ptr);
            println!("{}", ptr.read_volatile());
        }
    }
}