Fix target_env in avr-unknown-gnu-atmega328

[madsmtm]

The target name itself contains GNU, we should probably reflect that as target_env = "gnu" as well? Or from my reading of #74941 (comment), perhaps not, but then that should probably be documented somewhere?

There's no listed target maintainer, but the target was introduced in #74941, so I'll ping the author of that: @dylanmckay

Relatedly, I wonder why the recommendation is to create separate target triples for each AVR, when -Ctarget-cpu=... would suffice, perhaps you could also elaborate on that? Was it just because -Ctarget-cpu=... didn't exist back then? If so, now that it does, should we now change the target back to e.g. avr-unknown-none-gnu, and require the user to set -Ctarget-cpu=... instead?

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[jieyouxu]

Relatedly, I wonder why the recommendation is to create separate target triples for each AVR, when -Ctarget-cpu=... would suffice, perhaps you could also elaborate on that? Was it just because -Ctarget-cpu=... didn't exist back then? If so, now that it does, should we now change the target back to e.g. avr-unknown-none-gnu, and require the user to set -Ctarget-cpu=... instead?

My understanding at present is that if these AVR targets contain specific ABI-affecting codegen options / target features differences, including -Ctarget-cpu=..., having different targets is less prone to accidentally mixing code compiled with different incompatible ABI from different codegen flags. Crates that gets compiled by distinct targets like with avr-atmega1280.json target spec will be declared incompatible by rustc against code that is from a different target spec like avr-atmega1280.json. See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60-Ctarget-feature.3D.2Bsoft-float.60.20considered.20harmful and related discussion.

[workingjubilee]

I believe target_env = "gnu" is correct.

[madsmtm]

Relatedly, I wonder why the recommendation is to create separate target triples for each AVR, when -Ctarget-cpu=... would suffice, perhaps you could also elaborate on that? Was it just because -Ctarget-cpu=... didn't exist back then? If so, now that it does, should we now change the target back to e.g. avr-unknown-none-gnu, and require the user to set -Ctarget-cpu=... instead?

My understanding at present is that if these AVR targets contain specific ABI-affecting codegen options / target features differences, including -Ctarget-cpu=..., having different targets is less prone to accidentally mixing code compiled with different incompatible ABI from different codegen flags. Crates that gets compiled by distinct targets like with avr-atmega1280.json target spec will be declared incompatible by rustc against code that is from a different target spec like avr-atmega1280.json. See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60-Ctarget-feature.3D.2Bsoft-float.60.20considered.20harmful and related discussion.

Thanks for the clarification; IMO, that sounds like a bug in rustc or the linker, then, if we're allowing linking object files with different incompatible CPU types?

[jieyouxu]

Thanks for the clarification; IMO, that sounds like a bug in rustc or the linker, then, if we're allowing linking object files with different incompatible CPU types?

This is a known general class of problems where we should indeed be tracking ABI-affecting target features / codegen options and detecting if we're trying to link (build? not sure exactly at what time the detection is going to happen) things together with incompatibile options. It needs further some design work and follow-up implementation, but a possible design was discussed in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/stabilizing.20compiler.20flags.20for.20Rust-for-Linux.

(You can search the issue tracker for A-ABI flag and see how many of those we have)

[workingjubilee]

cc @Rahix

[madsmtm]

I'll add that this is especially relevant now for cc, which would like to get some of its target information from rustc, and that's complicated in general by targets not living in tree.

[jieyouxu]

I'll add that this is especially relevant now for cc, which would like to get some of its target information from rustc, and that's complicated in general by targets not living in tree.

rustc supports arbitrary target specs, albeit not stable, so AFAIK you might have to do something like

rust/src/tools/compiletest/src/common.rs

Line 496 in 5384697

&["--print=all-target-specs-json", "-Zunstable-options"],

Not sure exactly about your use case in cc specifically, probably worth opening a dedicated #t-compiler thread.

[madsmtm]

I'll add that this is especially relevant now for cc, which would like to get some of its target information from rustc, and that's complicated in general by targets not living in tree.

rustc supports arbitrary target specs, albeit not stable, so AFAIK you might have to do something like

rust/src/tools/compiletest/src/common.rs

Line 496 in 5384697

&["--print=all-target-specs-json", "-Zunstable-options"],

Not sure exactly about your use case in cc specifically, probably worth opening a dedicated #t-compiler thread.

I meant, --print=all-target-specs-json does not (and cannot) include targets defined in external json files, such as is commonly done here, so supporting those targets in cc is harder.

[Rahix]

I think this is correct from my point of view. But just in case, cc @Patryk27 as he's way better versed in the details of the AVR target than me :)

Relatedly, I wonder why the recommendation is to create separate target triples for each AVR, when -Ctarget-cpu=... would suffice, perhaps you could also elaborate on that? Was it just because -Ctarget-cpu=... didn't exist back then? If so, now that it does, should we now change the target back to e.g. avr-unknown-none-gnu, and require the user to set -Ctarget-cpu=... instead?

So this is something that seems to have flown past me completely. I'll have to have a play with it to see if -Ctarget-cpu can fully replace our current custom targets. We're currently adding a few more things to the target spec but from a quick glance, the majority of this should be replaceable by compiler options.

[BoxyUwU]

r? compiler

[madsmtm]

I'll have to have a play with it to see if -Ctarget-cpu can fully replace our current custom targets. We're currently adding a few more things to the target spec but from a quick glance, the majority of this should be replaceable by compiler options.

Cool! I've opened Rahix/avr-hal#586 to track it in a more appropriate place than this PR, sorry for the indirection.

[Patryk27]

I'm not sure on the original design, but I'd be up for using just -Ctarget-cpu - just note that different AVR targets need different pre-link-args as well 👀

[madsmtm]

I'm not sure on the original design, but I'd be up for using just -Ctarget-cpu - just note that different AVR targets need different pre-link-args as well 👀

I can't speak for T-compiler here, but I suspect that they'd be fine with a match target.cpu { "..." => "some linker flag" } in rustc_codegen_ssa (depending on what the differing linker flags are).

[workingjubilee]

while also not capable of speaking with The Voice Of An Entire Team, if we had some folks sign up to be AVR maintainers officially, I think we'd be happy to be merge whatever small compiler changes are necessary. frankly, we'd finally have someone to stick with the caseload of AVR weirdness and making decisions on what is and is not a bug.

[Patryk27]

Sure, I've been handling AVR bugs for quite a while now and I don't mind doing it officially 🙂

[madsmtm]

Sure, I've been handling AVR bugs for quite a while now and I don't mind doing it officially 🙂

Nice! Could you file a PR that adds src/doc/rustc/src/platform-support/avr-unknown-gnu-atmega328.md, following the template? (and also update the top-level table and set the correct TargetMetadata in the target file) (at least I think that's the process).

I can also do it myself, but I think you know a lot more about the target, so you're probably better suited for providing the information.

[petrochenkov]

@bors r+ rollup

[bors]

📌 Commit 033fdda has been approved by petrochenkov

It is now in the queue for this repository.