RISC-V ELF multilibs

[Palmer Dabbelt]

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/