Compilation model

[bjorn3]

Or how to implement --crate-type and --emit. My proposal would be the following:

cargo-gccrs invokes gccrs once with -fPIC to get the crate metadata, an object file, an assembly file, ... as necessary/requested. For all emit types except link, the respective file generated by gccrs is directly passed to the user. For link depending on the crate type(s) one of more of the following will be done:

• bin: Gcc will be invoked with the right arguments to link the final executable.
• lib/rlib: The crate metadata, object file and if necessary LTO metadata are packaged in a single archive.
• dylib: Gcc will be invoked with the right arguments to link a dylib with all symbols exported and the crate metadata embedded in the dylib.
• cdylib: Gcc will be invoked with the right arguments to link a dylib with only #[no_mangle] symbols exported and crate metadata not embedded.
• staticlib: The object file combined with the object files of all dependencies (rust and native archives) will be bundled in a single archive without crate metadata.
• proc-macro: Gcc will be invoked with the right arguments to link a proc-macro. (will have to wait until gccrs supports proc macros)

Gccrs will then have to learn how to read crate metadata from rlibs and dylibs.

This proposal should solve the problem of having to invoke gcc multiple times when using multiple crate types or when using --emit obj,link or something like that. It is also somewhat close to what rustc internally does except that some logic is moved from rustc_codegen_ssa::back::link to cargo-gccrs. It may also be possible to implement this logic in the gcc driver so you have -frust-crate-type=bin,lib,dylib.

WDYT @philberty?

[philberty]

Thanks for this @bjorn3 that is how I see gccrs as well. There are a bunch of issues within GCCRS that need to be ironed out but this should really be the I guess architecture we are aiming for.

I am worried about losing this content in a GitHub issue, do you think it makes sense to make a wiki entry out of it over on gccrs? There are a bunch of tickets that need to be created here for the compiler. possibly in some way at least started with my imports and visibility milestone.

[bjorn3]

do you think it makes sense to make a wiki entry out of it over on gccrs?

Done: https://github.com/Rust-GCC/gccrs/wiki/Compilation-model-(proposal)