Set qemu cpu option from ELF attribute

[kito-cheng]

This could help multi-lib testing, but the price is slightly increase the testing time since it will need to extract ELF attribute from binary before running qemu.

But I think the cost is acceptable compare to make build system more complicate, and actually we already use this approach in our internal stuffs for years.

Fix #1206.

[kito-cheng]

@vineetgarc

[cmuellner]

missing space

[cmuellner]

Why not --get-riscv-tag?

[vineetgarc]

This could help multi-lib testing, but the price is slightly increase the testing time since it will need to extract ELF attribute from binary before running qemu.

But I think the cost is acceptable compare to make build system more complicate, and actually we already use this approach in our internal stuffs for years.

Fix #1206.

I'm still a bit wary of cost (delay) considering qemu runs are not currently parallelized.
I was thinking that a non-multilib can benefit from this change (as in rely on elf attribute) but the multilib cases are simple (at least today) and only need rv64 / rv32 for QEMU_CPU, nothing fancier (most other things are enabled by default in qemu anyways).

And multilib is what takes forover so we can help speed it up by avoiding all this (using additional makefile foo/bar) and with equivalent of following in run script.

-QEMU_CPU=${QEMU_CPU} qemu-riscv$xlen -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} "$@"
+QEMU_CPU=rv$xlen qemu-riscv$xlen -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} "$@"

[cmuellner]

I'm still a bit wary of cost (delay) considering qemu runs are not currently parallelized.

make -j$(nproc) report SIM=qemu runs a QEMU process on each core here.

I was thinking of proposing rv$XLEN as well, because QEMU enables many extensions by default.
However, this breaks for e.g. vendor extensions (and all standard extensions that are not enabled), which is certainly not what we want.

[kito-cheng]

This could help multi-lib testing, but the price is slightly increase the testing time since it will need to extract ELF attribute from binary before running qemu.
But I think the cost is acceptable compare to make build system more complicate, and actually we already use this approach in our internal stuffs for years.
Fix #1206.

I'm still a bit wary of cost (delay) considering qemu runs are not currently parallelized. I was thinking that a non-multilib can benefit from this change (as in rely on elf attribute) but the multilib cases are simple (at least today) and only need rv64 / rv32 for QEMU_CPU, nothing fancier (most other things are enabled by default in qemu anyways).

Not sure what yo mean about not parallelized? Gcc test suite should be parallelized just by -j I think?

And multilib is what takes forover so we can help speed it up by avoiding all this (using additional makefile foo/bar) and with equivalent of following in run script.

-QEMU_CPU=${QEMU_CPU} qemu-riscv$xlen -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} "$@"
+QEMU_CPU=rv$xlen qemu-riscv$xlen -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} "$@"

That seems can’t handle those extension not enabled by default?

[vineetgarc]

I'm still a bit wary of cost (delay) considering qemu runs are not currently parallelized.

make -j$(nproc) report SIM=qemu runs a QEMU process on each core here.

Ah I'm stupid. I was not passing -j to test run :-(

I was thinking of proposing rv$XLEN as well, because QEMU enables many extensions by default. However, this breaks for e.g. vendor extensions (and all standard extensions that are not enabled), which is certainly not what we want.

The point is those vendor extensions are not run as part of standard multilib runs. But anyways elf parsing feels more future proof so yes fine by me.