Pack size and alignment in vtables for CHERIoT

[xdoardo]

A potential solution for #48 - still a draft because I want to add tests to the generated LLVM IR for CHERIoT before merging, and I would also like to have #46 merged before merging this one.

The patch adds in_memory_size and data_size methods to the VtblEntry type so to make computations respect the different sizes of the entries on CHERI-like platforms (or any platform with non-integral pointers). These methods are used both to generate the vtable type in LLVM IR and to generate the debug info for the type.

For reference, this is what the vtable in the example in the issue now looks like:

@vtable.0 = private unnamed_addr addrspace(200) constant <{ ptr addrspace(200), [8 x i8], ptr addrspace(200) }> <{ ptr addrspace(200) @"_ZN4core3ptr37drop_in_place$LT$vtable..Monobloc$GT$17h68c892b65ff866f1E", [8 x i8] c"\18\00\00\00\08\00\00\00", ptr addrspace(200) @"_ZN50_$LT$vtable..Monobloc$u20$as$u20$vtable..Chair$GT$10count_legs17h0a91b89070da3234E" }>, align 8

Some questions

• How much will this patch degrade performance on targets where these computations are just trivial multiplications? Should we split the computation in two functions, a "trivial" one for usual platforms and an "expensive" one for platforms with non-integral pointers?
• Is there a way to make sure that we're adding reasonable checks for other platforms with non-integral pointers, such as making sure the accesses to the vtable are aligned?

[seharris]

I think this assertion is broken, it passes for cases like usize_size = 8 bits, pointer_align = 64 bits which I don't think is correct.