Ah OK. So this boils down to the difference between configs for targets
and configs for toolchains. Configs for targets should be precise as
possible [1], and `riscv-*` makes no sense. Configs for tools are
actually the *set* of configs the tool targets and so `riscv-` does
indeed make make perfect sense [2]. So we can add a flag to gnu config
(with sensible default) to only allow stuff like this for the latter
tool case. We could also choose to add another shell script answering
"does (tool) config a cover config b", codifying that relation. I would
volunteer to do both of these things if a RISC-V person can give me a
table with the intend relation.
I agree with the gist of what Earnie says. To preserve symmetry and not
surprise the user with weird defaults, I'd say a `riscv-*` tool-chain
shouldn't default to 32-bit, 64-bit, or anything else. So the `-m64` or
whatever is required. Or perhaps to make native compilation a bit easier
a RISC-V tool chain should *only* default to a specific variant of
RISC-V if that platform is the host platform, so cross compilation must
be explicit, but native compilation with explicit-config tools can be
implicit.
John
[1] Configs for targets are more known with LLVM than GNU tools, and
their `-target` flag. But certain GNU binutils (e.g. objdump) do support
`--target` so it's not just an LLVMism.
[2] Yet another example of autotools and friends forcing a single target
platform muddying the waters.
On 06/21/18 13:49, Earnie wrote:
On 6/20/2018 7:55 PM, Palmer Dabbelt wrote:
The one saving grace here is that most of the RISC-V toolchains support
generating code for all targets -- in other words "riscv32-*-gcc
-march=rv64gc" is a valid thing to do, and will generate 64-bit code
(and links against a 64-bit libc). As a result, none of this actually
matters.
Given this I can understand the frustration of needing the 32/64
specifier. I would then suggest the patch removes riscv32 and riscv64
specifics and use riscv* instead. I.E. use riscv*-* as the filter.
_______________________________________________
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches
