RFC: Add target_abi configuration by nvzqz · Pull Request #2992 · rust-lang/rfcs (original) (raw)

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

This proposes a new cfg: target_abi, which specifies certain aspects of the target's Application Binary Interface (ABI). This also adds a CARGO_CFG_TARGET_ABI environment variable for parity with other CARGO_CFG_TARGET_* variables.

Rendered

Hermitter, AlieGG, AaronKutch, GrayJack, pravic, madsmtm, and cher-nov reacted with thumbs up emoji thomcc, bbqsrc, DianaNites, Hermitter, AlieGG, GrayJack, and attila-lin reacted with rocket emoji

jonas-schievink added A-cfg

Conditional compilation related proposals & ideas

A-target

Target related proposals & ideas

T-lang

Relevant to the language team, which will review and decide on the RFC.

labels

Sep 27, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does rustc already have the concept of target ABI internally? If not it seems really important to spell out how exactly this is defined. The concept of ABIs is really poorly understood by developers in my experience. Obviously there's a 1:1 mapping of target : ABI, but the inverse mapping is a little fuzzy to me and I'm not sure how useful it is in practice.

For example, I'm not really aware of an existing convention for talking about the "x86-64 System V ABI" despite it being the ABI used in both x86-64 Linux and macOS.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifically what I'm interested in is the component that comes after target_env in the triple string. What it indicates varies greatly between different targets. On some targets, it indicates the availability of hardware floats (e.g. eabihf for embedded abi, hardware float). On others, it indicates the running environment (e.g. x86_64-apple-ios-macabi for iOS apps that target macOS).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this in the @rust-lang/lang meeting today. We're entirely in favor of doing this, and we just had one question:

Does this propose to change the value of target_env on any platform? Are there any platforms where the target_env contains the environment and the ABI concatenated together? target_env would need to keep its current value on those platforms, for compatibility.

If there's no compatibility break here, then 👍 for this RFC.

@rfcbot merge
@rfcbot concern compatibility

Does this propose to change the value of target_env on any platform? Are there any platforms where the target_env contains the environment and the ABI concatenated together? target_env would need to keep its current value on those platforms, for compatibility.

If you're talking about targets like ARM, where the RFC says:

Embedded ABIs such as gnueabihf will define target_env as "gnu" and target_abi as "eabihf".

ARM Linux already has a simple target_env="gnu" (or "musl"), and there's no cfg reflecting such "eabihf" parts yet. However, it looks like a few arm*bsd targets do have the ABI in target_env. Those are Tier 3, and IMO should be fixed.

@cuviper Sounds reasonable. Could you please file an issue that lists the targets you found? We should also search the crater code corpus for instances of those target names to evaluate impact. And we should add some documentation in the codebase in places people will see when adding a new target, to make it clear that target_env should not include any ABI-related suffixes like eabi or eabihf.

@rfcbot resolved compatibility

🔔 This is now entering its final comment period, as per the review above. 🔔

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

Huzzah! The @rust-lang/lang team has decided to accept this RFC.

To track further discussion, subscribe to the tracking issue here:
rust-lang/rust#80970

nvzqz deleted the cfg-target-abi branch

January 13, 2021 05:00

This was referenced

Nov 4, 2022