Abi Descriptors

[ionicmc-rs]

Allows for creating custom ABIs in Rust.

this should still map to something that works in LLVM, the exact details are still to be decided

Important

When responding to RFCs, try to use inline review comments (it is possible to leave an inline review comment for the entire file at the top) instead of direct comments for normal comments and keep normal comments for procedural matters like starting FCPs.

This keeps the discussion more organized.

Rendered

[tgross35]

This just isn't enough to represent anything more than trivial ABIs. Different types may have different stack alignment, different float/int sizes may get passed in different registers, values may be split across registers, ADTs need to be figured out, etc...

[ionicmc-rs]

Yeah I also thought that could be a problem.

I'm not an expert on what an ABI really does, but there should be some possible way to allow for ABI defs in rust.

I'm going to try and gather a bit more information and adjust the implementation

[ionicmc-rs]

Ok i have thought of a better way to do this, im going to say it here before changing the RFC:

We can have special "abi" crates (like proc-macro) that can only export ABI defs.

Example:

Cargo.toml

[lib]
abi = true
# proc-macro = true
# this fails

lib.rs:

extern crate abi;

use abi::{Alignment, AbiTable, BasicType}; // basic types are unsigned interger

#[abi(align_for /*, method specific options */)]
pub fn align_for(ty: BasicType) -> Alignment {
    match ty {
         // ... 
         BasicType::U8 => Alignment::One
    }
}

#[abi(table, name="custom_abi")]
pub const CUSTOM_ABI: AbiTable = AbiTable::new()
     .set_align_for(ty);

Usage:

use abi_crate::CUSTOM_ABI; // required import

extern "custom_abi" fn do_nothing() {}

This offers more functionality, while keeping familiar API to users of Rust

I want to state again that this may not be the best way, and that i am not an expert.

[clarfonthey]

I'm not an expert on what an ABI really does

You should not be writing a proposal for a full ABI definition framework which is permanently stable and cannot be changed unless you know what an ABI is and what it does. This doesn't mean that the idea doesn't have merit, but as someone who also does not fully understand ABIs, I at least am past the Dunning-Kruger curve enough to realise that defining an ABI using a simple trait does not seem sufficient in the slightest.

Not even LLVM seems to even attempt to tackle this goal. What makes you think that Rust can and should?

Just take a brief look at the closest similar proposal, to add crABI, and see if your proposal covers 1% of the requirements or answers 1% of the questions left open: rust-lang/compiler-team#631

[tgross35]

I kind of hinted at this in my other comment but IMO, any sort of proposal to express ABI in code is a non-starter. There is an immense amount of complexity (see all the LLVM tablegen files related to ABI) and little reason not to do things in assembly.

There are certainly problems with handwritten assembly that could be improved if you are interested, but I think this is better framed as “how can we make it easier to integrate handwritten assembly (like trampolines) with normal code” rather than trying to, effectively, get rustc to emit a very specific assembly without writing it.