build system: use riscv-none-elf as triplet

[maribu]

Contribution description

Use riscv-none-elf instead of legacy riscv-none-embed as target triplet for RISC-V development. However, if ricsv-none-elf is not present but riscv-none-embed is, fall back to legacy triplet (and print an info message about this behavior).

Testing procedure

E.g. make BOARD=hifive1 -C examples/default and make BUILD_IN_DOCKER=1 BOARD=hifive1 -C examples/default should now work both, even if the local toolchain is build from upstream sources (which requires riscv-none-elf as triplet).

Issues/PRs references

None

[benpicco]

On Ubuntu I got riscv64-unknown-elf- from the repository, following the naming introduced by Debian.
Despite the name it also builds the code for our 32 bit RiscV targets just fine - I haven't tested in on real hardware yet.

[maribu]

On Ubuntu I got riscv64-unknown-elf- from the repository, following the naming introduced by Debian.
Despite the name it also builds the code for our 32 bit RiscV targets just fine - I haven't tested in on real hardware yet.

My riscv-none-elf also builds for 64 bit; the cross compilation toolchains can be build with multilib and multiarch support.

However, the unknown is IMO not correct. According to the clang documentation regarding the target triple, using unknown will result in the defaults being used. Apparently, this currently seems to be none for the system part of the triple. But IMO it makes much more sense to explicitly use none there, so that if unknown stops defaulting to none the semantics don't change and it is more obvious what the system actually is. I filed bugs in Debian, Ubuntu and Arch Linux. Let's see if they fix the target triple.

[kaspar030]

This might need updating the CI, as it is using the eclipse gcc packages, which IIRC introduced this -embed thingy. triggering to see...

[kaspar030]

This might need updating the CI, as it is using the eclipse gcc packages, which IIRC introduced this -embed thingy. triggering to see...

seems like the logic works as expected.

[fjmolinas]

@maribu can you rebase?

This might need updating the CI, as it is using the eclipse gcc packages, which IIRC introduced this -embed thingy. triggering to see...

seems like the logic works as expected.

Can we interpret it as an ACK? :)

[maribu]

I wonder if it doesn't make sense to also include riscv64-unknown-elf, as this is currently the most popular triplet. (Even though IMO it should be riscv64-none-elf.)

[maribu]

@benpicco: Can you test this on your Ubuntu / Debian machine to check if RISCV is now using the toolchain shipped by the package manager?

[fjmolinas]

ping @maribu @benpicco

[maribu]

I think this is good to go.

One might want to re-evalute the order in which the toolchains are tested for. Currently it will test first for riscv-none-elf and only afterwards for riscv64-unknown-elf. The former is what is actually correct:

• We are currently only targeting 32 bit RISV processors. Most toolchains are multilib and support all 32 bit and 64 bit flavors. But a toolchain could also be compiled as 32 bit or 64 bit only. In that case riscv-* would work, but riscv64-* wouldn't.
• The *-unknown-* is not correct. On bare metal embedded targets the system should be none. Using unknown means that the compiler should choose the default option, which for the system part of the triple currently is none. But it would certainly be better to be explicit.

However, most distros (Debian, Ubuntu, Arch Linux) only provide riscv64-unknown-elf which has multilib enabled. So: Should we prefer the correct triple (as is done now), or should we prefer the most widely used one?

I believe that the overhead for testing is hardly noticeable. So maybe this might not be terribly important.

We also might want to eventually phase out riscv-none-embed, as that triple is defunct on upstream GCC and binutils. Only a legacy binary eclipse toolchain uses that. But we should update the docker image used by the CI first, to not break it. So that should be a follow up for when the docker image is updated and deployed on all CI workers.

[fjmolinas]

@bergzand do you have an opinion on this? You have been looking into risc-v quite a lot.