On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote:
On 05/26/2018 06:04 AM, Sebastian Huber wrote:
Why is the default multilib and a variant identical?
This is supposed to be a single multilib, with two names. We use
MULTILIB_REUSE to map the two names to a single multilib.
rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc
./rv64imafdc/lp64d/libgcc.a
rohan:1031$ ./xgcc -B./ -march=rv64gc -mabi=lp64d --print-libgcc
./rv64imafdc/lp64d/libgcc.a
rohan:1032$ ./xgcc -B./ --print-libgcc
./libgcc.a
rohan:1033$
So this is working right when the -march option is given, but not when
no -march is given. I'd suggest a bug report so I can track this, if
you haven't already filed one.
IIRC this is actually a limit of the GCC build system: there needs to be some
default multilib, and it has to be unprefixed. I wanted to keep the library
paths orthogonal (ie, not bake in a default that rv64gc/lp64d lives at /lib),
so I chose to just build a redundant multilib.
It'd be great to get rid of this, but I'm afraid it's way past my level of
understanding as to how all this works.
Most variants include the C extension. Would it be possible to add -march=rv32g
and -march=rv64g variants?
The expectation is that most implementations will include the C
extension. It reduces code size, improves performance, and I think I
read somewhere that it takes only 400 gates to implement.
It isn't practical to try to support every possible combination of
architecture and ABI here, as there are too many possible combinations.
But if there is a major RISC-V target that is rv32g or rv64g then we
should consider it. You can of course define your own set of multilibs.
While that's the standard answer, note that Sebastian added the RISC-V RTEMS
target in the first place so as far as I'm concerned he can add additional
multilibs to it if he wants. While I'm not opposed to RTEMS multilibs for
rv32g/ilp32d and rv64g/lp64d, note that we have made the decision in Linux land
that the C extension will be common and thus I expect most RISC-V
implementations with virtual memory to also have the C extension. If you go
down this route then you should move RTEMS to its own multilib target fragment
(t-rtems-multilib or something similar).
If you need help figuring out the patch feel free to ask. I wrote a blog that
might be useful
https://www.sifive.com/blog/2017/09/18/all-aboard-part-5-risc-v-multilib/
