Proper MSVC support

[RaitoBezarius]

I opened #116 and realized actually that the create_object_file might be crippled to not output COFF files (I don't know how to read at 2AM, ignore.) and that generally parsing target strings won't give you the fact that x86_64-unknown-uefi is in fact MSVC.

Same for custom targets.

So I would like to open this issue to discuss how to design proper multi-platform support for this project, I am very interested to have this data in UEFI programs for example (which can afford some kb of extra data, contradicting a bit the README on embedded but it's okay).

I would like to import rustc_codegen_ssa properly and hook also a proper way to detect the structured target information and retrieve the linker argument style (GNU or MSVC for example) so we can have nice things™.

What do you think?

[Shnatsel]

I'd like to have a hardcoded list of MSVC platforms initially, so we can quickly ship a hotfix and people can easily upgrade without extra dependencies, etc (which is a problem for organizations and linux distros).

I'm not keen on depending on rustc internals because they are subject to change, and can be quite heavyweight, so I was hoping that the platforms crate would be sufficient. Unfortunately it is not, and even rustc --print=cfg --target x86_64-unknown-uefi does not provide any clues about it being in fact MSVC. At a glance target_lexicon doesn't seem sufficient either.

Unfortunately the rustc_codegen_ssa crate is not published to crates.io, so there's no good way to depend on it without git dependencies. I'm not sure if publishing crates with git dependencies is even allowed on crates.io.

[Shnatsel]

Right now we rely on a bit of code copied from rustc for figuring out the proper flags for platforms: https://github.com/rust-secure-code/cargo-auditable/blob/master/cargo-auditable/src/object_file.rs

It's not great but it works for all but the most obscure tier-3 targets. I suppose a similar approach could be taken here, if that code turns out to be self-contained?

[RaitoBezarius]

Hmmmm, I see your point, I guess there's no easy way around. I would still push for an open API on Cargo side or Rustc side because this is a real usecase. And in the meantime, we can hack our way around.

[Shnatsel]

Yes, we'll need some proper APIs around target information to get this upstreamed into Cargo. I doubt copy-pasted code will fly.

[RaitoBezarius]

(also you might be interested to know that nixpkgs has enabled cargo-auditable on "all packages where it can", meaning all our Rust binaries compiled and published in our binary cache has the auditable information. https://github.com/NixOS/nixpkgs/pull/223320)

[Shnatsel]

Since MSVC targets pass all tests on CI, and this issue is based on reading docs rather than actual testing, I'm going to go ahead and close this.

If you run into issues with MSVC toolchain when actually using cargo auditable, please file a new issue and include the error message.