Implement most of MCP510 by lqd · Pull Request #112910 · rust-lang/rust (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 }})
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Status: Awaiting review from the assignee but also interested parties.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
linker flavors
- only the stable values for
-Clink-self-containedcan be used on stable until we have more feedback on the interface -Zunstable-optionsis required to use unstable linker flavors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
make MCP510 behavior opt-in to avoid conflicts between the CLI and target flavors
Fixes rust-lang#113597, which contains more details on how this happens through the code, and showcases an unexpected Gnu(Cc::Yes, Lld::Yes) flavor.
rust-lang#112910 added support to use lld when the flavor requests it, but didn't explicitly do so only when using -Clink-self-contained=+linker or one of the unstable -Clinker-flavors.
The problem: some targets have a lld linker and flavor, e.g. thumbv6m-none-eabi from that issue. Users can override the linker but there are no linker flavors precise enough to describe the linker opting out of lld: when using -Clinker=arm-none-eabi-gcc, we infer this is a Cc::Yes linker flavor, but the lld component is unknown and therefore defaulted to the target's linker flavor, Lld::Yes.
Walkthrough of how this happens
The linker flavor used is a mix between what can be inferred from the CLI (-C linker) and the target's default linker flavor:
- there is no linker flavor on the CLI (and that also offers another workaround on nightly:
-C linker-flavor=gnu-cc -Zunstable-options), so it will have to be inferred from here to here. - in
infer_linker_hints-C linker=arm-none-eabi-gccinfers aSome(Cc::Yes)cc hint, and no hint about lld. - the target's
linker_flavoris combined inwith_cli_hintswith these hints. We have ourCc::Yes, but there is no hint about lld, so the target's flavorlldcomponent is used. It'sGnu(Cc::No, Lld::Yes). - so we now have our
Gnu(Cc::Yes, Lld::Yes)flavor
This results in a Gnu(Cc::Yes, Lld::Yes) flavor on a non-lld linker, causing an additional unexpected -fuse-ld=lld argument to be passed.
I don't know if this target defaulting to rust-lld is expected, but until MCP510's new linker flavor are stable, when people will be able to describe their linker/flavor accurately, this PR keeps the stable behavior of not doing anything when the linker/flavor on the CLI unexpectedly conflict with the target's.
I've tested this on a no_std -C linker=arm-none-eabi-gcc -C link-arg=-nostartfiles --target thumbv6m-none-eabi example, trying to simulate one of cortex-m's test mentioned in issue rust-lang#113597 (I don't know how to build a local complete thumbv6m-none-eabi toolchain to run the exact test), and checked that -fuse-lld was indeed gone and the error disappeared.
r? @petrochenkov
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
make MCP510 behavior opt-in to avoid conflicts between the CLI and target flavors
Fixes rust-lang#113597, which contains more details on how this happens through the code, and showcases an unexpected Gnu(Cc::Yes, Lld::Yes) flavor.
rust-lang#112910 added support to use lld when the flavor requests it, but didn't explicitly do so only when using -Clink-self-contained=+linker or one of the unstable -Clinker-flavors.
The problem: some targets have a lld linker and flavor, e.g. thumbv6m-none-eabi from that issue. Users can override the linker but there are no linker flavors precise enough to describe the linker opting out of lld: when using -Clinker=arm-none-eabi-gcc, we infer this is a Cc::Yes linker flavor, but the lld component is unknown and therefore defaulted to the target's linker flavor, Lld::Yes.
Walkthrough of how this happens
The linker flavor used is a mix between what can be inferred from the CLI (-C linker) and the target's default linker flavor:
- there is no linker flavor on the CLI (and that also offers another workaround on nightly:
-C linker-flavor=gnu-cc -Zunstable-options), so it will have to be inferred from here to here. - in
infer_linker_hints-C linker=arm-none-eabi-gccinfers aSome(Cc::Yes)cc hint, and no hint about lld. - the target's
linker_flavoris combined inwith_cli_hintswith these hints. We have ourCc::Yes, but there is no hint about lld, so the target's flavorlldcomponent is used. It'sGnu(Cc::No, Lld::Yes). - so we now have our
Gnu(Cc::Yes, Lld::Yes)flavor
This results in a Gnu(Cc::Yes, Lld::Yes) flavor on a non-lld linker, causing an additional unexpected -fuse-ld=lld argument to be passed.
I don't know if this target defaulting to rust-lld is expected, but until MCP510's new linker flavor are stable, when people will be able to describe their linker/flavor accurately, this PR keeps the stable behavior of not doing anything when the linker/flavor on the CLI unexpectedly conflict with the target's.
I've tested this on a no_std -C linker=arm-none-eabi-gcc -C link-arg=-nostartfiles --target thumbv6m-none-eabi example, trying to simulate one of cortex-m's test mentioned in issue rust-lang#113597 (I don't know how to build a local complete thumbv6m-none-eabi toolchain to run the exact test), and checked that -fuse-lld was indeed gone and the error disappeared.
r? @petrochenkov
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
make MCP510 behavior opt-in to avoid conflicts between the CLI and target flavors
Fixes rust-lang#113597, which contains more details on how this happens through the code, and showcases an unexpected Gnu(Cc::Yes, Lld::Yes) flavor.
rust-lang#112910 added support to use lld when the flavor requests it, but didn't explicitly do so only when using -Clink-self-contained=+linker or one of the unstable -Clinker-flavors.
The problem: some targets have a lld linker and flavor, e.g. thumbv6m-none-eabi from that issue. Users can override the linker but there are no linker flavors precise enough to describe the linker opting out of lld: when using -Clinker=arm-none-eabi-gcc, we infer this is a Cc::Yes linker flavor, but the lld component is unknown and therefore defaulted to the target's linker flavor, Lld::Yes.
Walkthrough of how this happens
The linker flavor used is a mix between what can be inferred from the CLI (-C linker) and the target's default linker flavor:
- there is no linker flavor on the CLI (and that also offers another workaround on nightly:
-C linker-flavor=gnu-cc -Zunstable-options), so it will have to be inferred from here to here. - in
infer_linker_hints-C linker=arm-none-eabi-gccinfers aSome(Cc::Yes)cc hint, and no hint about lld. - the target's
linker_flavoris combined inwith_cli_hintswith these hints. We have ourCc::Yes, but there is no hint about lld, so the target's flavorlldcomponent is used. It'sGnu(Cc::No, Lld::Yes). - so we now have our
Gnu(Cc::Yes, Lld::Yes)flavor
This results in a Gnu(Cc::Yes, Lld::Yes) flavor on a non-lld linker, causing an additional unexpected -fuse-ld=lld argument to be passed.
I don't know if this target defaulting to rust-lld is expected, but until MCP510's new linker flavor are stable, when people will be able to describe their linker/flavor accurately, this PR keeps the stable behavior of not doing anything when the linker/flavor on the CLI unexpectedly conflict with the target's.
I've tested this on a no_std -C linker=arm-none-eabi-gcc -C link-arg=-nostartfiles --target thumbv6m-none-eabi example, trying to simulate one of cortex-m's test mentioned in issue rust-lang#113597 (I don't know how to build a local complete thumbv6m-none-eabi toolchain to run the exact test), and checked that -fuse-lld was indeed gone and the error disappeared.
r? @petrochenkov
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
make MCP510 behavior opt-in to avoid conflicts between the CLI and target flavors
Fixes rust-lang#113597, which contains more details on how this happens through the code, and showcases an unexpected Gnu(Cc::Yes, Lld::Yes) flavor.
rust-lang#112910 added support to use lld when the flavor requests it, but didn't explicitly do so only when using -Clink-self-contained=+linker or one of the unstable -Clinker-flavors.
The problem: some targets have a lld linker and flavor, e.g. thumbv6m-none-eabi from that issue. Users can override the linker but there are no linker flavors precise enough to describe the linker opting out of lld: when using -Clinker=arm-none-eabi-gcc, we infer this is a Cc::Yes linker flavor, but the lld component is unknown and therefore defaulted to the target's linker flavor, Lld::Yes.
Walkthrough of how this happens
The linker flavor used is a mix between what can be inferred from the CLI (-C linker) and the target's default linker flavor:
- there is no linker flavor on the CLI (and that also offers another workaround on nightly:
-C linker-flavor=gnu-cc -Zunstable-options), so it will have to be inferred from here to here. - in
infer_linker_hints-C linker=arm-none-eabi-gccinfers aSome(Cc::Yes)cc hint, and no hint about lld. - the target's
linker_flavoris combined inwith_cli_hintswith these hints. We have ourCc::Yes, but there is no hint about lld, so the target's flavorlldcomponent is used. It'sGnu(Cc::No, Lld::Yes). - so we now have our
Gnu(Cc::Yes, Lld::Yes)flavor
This results in a Gnu(Cc::Yes, Lld::Yes) flavor on a non-lld linker, causing an additional unexpected -fuse-ld=lld argument to be passed.
I don't know if this target defaulting to rust-lld is expected, but until MCP510's new linker flavor are stable, when people will be able to describe their linker/flavor accurately, this PR keeps the stable behavior of not doing anything when the linker/flavor on the CLI unexpectedly conflict with the target's.
I've tested this on a no_std -C linker=arm-none-eabi-gcc -C link-arg=-nostartfiles --target thumbv6m-none-eabi example, trying to simulate one of cortex-m's test mentioned in issue rust-lang#113597 (I don't know how to build a local complete thumbv6m-none-eabi toolchain to run the exact test), and checked that -fuse-lld was indeed gone and the error disappeared.
r? @petrochenkov
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
make MCP510 behavior opt-in to avoid conflicts between the CLI and target flavors
Fixes rust-lang#113597, which contains more details on how this happens through the code, and showcases an unexpected Gnu(Cc::Yes, Lld::Yes) flavor.
rust-lang#112910 added support to use lld when the flavor requests it, but didn't explicitly do so only when using -Clink-self-contained=+linker or one of the unstable -Clinker-flavors.
The problem: some targets have a lld linker and flavor, e.g. thumbv6m-none-eabi from that issue. Users can override the linker but there are no linker flavors precise enough to describe the linker opting out of lld: when using -Clinker=arm-none-eabi-gcc, we infer this is a Cc::Yes linker flavor, but the lld component is unknown and therefore defaulted to the target's linker flavor, Lld::Yes.
Walkthrough of how this happens
The linker flavor used is a mix between what can be inferred from the CLI (-C linker) and the target's default linker flavor:
- there is no linker flavor on the CLI (and that also offers another workaround on nightly:
-C linker-flavor=gnu-cc -Zunstable-options), so it will have to be inferred from here to here. - in
infer_linker_hints-C linker=arm-none-eabi-gccinfers aSome(Cc::Yes)cc hint, and no hint about lld. - the target's
linker_flavoris combined inwith_cli_hintswith these hints. We have ourCc::Yes, but there is no hint about lld, so the target's flavorlldcomponent is used. It'sGnu(Cc::No, Lld::Yes). - so we now have our
Gnu(Cc::Yes, Lld::Yes)flavor
This results in a Gnu(Cc::Yes, Lld::Yes) flavor on a non-lld linker, causing an additional unexpected -fuse-ld=lld argument to be passed.
I don't know if this target defaulting to rust-lld is expected, but until MCP510's new linker flavor are stable, when people will be able to describe their linker/flavor accurately, this PR keeps the stable behavior of not doing anything when the linker/flavor on the CLI unexpectedly conflict with the target's.
I've tested this on a no_std -C linker=arm-none-eabi-gcc -C link-arg=-nostartfiles --target thumbv6m-none-eabi example, trying to simulate one of cortex-m's test mentioned in issue rust-lang#113597 (I don't know how to build a local complete thumbv6m-none-eabi toolchain to run the exact test), and checked that -fuse-lld was indeed gone and the error disappeared.
r? @petrochenkov