Cannot transmute between types of different sizes.

[uwecerron]

Running into this issue with rustc 1.59.0

= note: source type: InnerNode (384 bits)
= note: target type: critbit::_::{closure#0}::TypeWithoutPadding (256 bits)

[Lcchy]

Hi,
Can you please post your solana --version?
Are you importing the AOB with some specific features?
Thanks

[uwecerron]

@Lcchy solana-cli 1.9.13 (src:3ac7e043; feat:1070292356), no just doing a cargo build

[pindaroso]

Bump :)

[Lcchy]

All right, can you tell me which OS you are using? I don't see where this could be coming from right now, but I suspect some versioning/dependency issue. I am trying to reproduce it.

[dr497]

I confirm I cannot reproduce either.

Could you upload a minimal example on Github so we can help?

[uwecerron]

sorry for delay in responding, a macbook pro , Monterey OS, Apple M1 Pro chip

[Lcchy]

We tested it on an M1 cpu and we're indeed getting the same error. We will look into it but we don't expect to find something quickly as the error is linked to how Rust interacts with the hardware, sorry.

For the record, adding #[repr(C, align(8))] to the struct to force byte alignment does not help

[callensm]

bump on this issue.

only seems to be an issue when targeting the aarch64 architecture - x86_64 builds without error.

is there a fix being implemented for this?

[ellttBen]

HI @callensm, so we don't have an M1 Mac to properly test this, but my best recommendation would be to run try and compile + run through Rosetta. This repository might be of some help https://github.com/FdezRomero/rosetta-cli.
In general we're not really too worried about this : we build programs for the Solana VM which has a fixed architecture (BPF), which means we don't really need to worry about portability of the program itself, which is why I think that it's actually necessary for any Solana developer to have a development environment which is compatible with the Solana VM's architecture. I hope this can be achieved through Rosetta.
In any case, we might implement some feature flags to enable limited compatibility with different architectures.
Another element is that reading through the M1 arch docs I don't see the difference with BPF and x86_64, which makes me wonder if this might be a compilation issue with rustc (maybe there is a way to configure the compilator to fix this).

[callensm]

requiring rosetta doesn't seem like a reasonable solution. there are fixes to these alignment issues and the remainder of the rust and solana ecosystems natively support the aarch64 now.

[ellttBen]

We chose to use bytemuck in our programs, which makes extensive use of direct type casting. This means that the way we write define our structs and data structures is highly specific to the BPF and x86_64 architectures. Maybe there is a solution I'm not seeing here, and I'd be open to suggestions, but to me it seems like it's out of our hands, at least as long as we want to keep using the most efficient data structures for our particular problems.

[ellttBen]

I looked a bit more into it and found this issue : solana-labs/solana#21269. It seems that the issue stems from different u128 alignment requirements. I've made an attempt to solve this issue in PR #64. If anyone with an M1 Mac can test this out, it would be of great help!

[callensm]

I looked a bit more into it and found this issue : solana-labs/solana#21269. It seems that the issue stems from different u128 alignment requirements. I've made an attempt to solve this issue in PR #64. If anyone with an M1 Mac can test this out, it would be of great help!

Just checked and this does resolve the aarch64 build target error.

Thank you!

[callensm]

I think this issue can be closed, since the merge of #64

[uwecerron]

seems like aarch64 branch changes were lost, just tried to recompile on an m1 and it's not compiling again.

[ellttBen]

Hi @uwecerron! Looking at the code right now I'm not sure I understand where this might be coming from. Would you mind posting the error you're getting?
Reopening in the meantime.

To be clear we just redefined the structs to not necessitate aarch64-specific code. Interested to see where we got it wrong

[ellttBen]

We have a working solution for this in the pipeline at #82. Once we're done with review we should be able to mainline this. The only issue I am seeing is that developers down the line will have to specifically support the aarch64 architecture since the struct definitions change.
u128 is a really problematic type in rustc right now, and this seems to be due to a long standing LLVM bug [1]. In theory aarch64 and x86_64 should have the exact same alignment requirements for u128 but this isn't the case. This is actually quite fortunate for us since this means that x86_64 has the same constraints as the eBPF architecture, which makes our job easier when on x86_64.
Once this bug is resolved we might have to rewrite the AOB to natively use [u64;2] in its logic, but since the issue won't be resolved anytime soon I am not sure it's worth it right now.

[1] rust-lang/rust#54341