Re: RISC-V ELF multilibs

[Sebastian Huber <sebastian.huber@embedded-brains.de>]

On 31/05/18 11:08, Palmer Dabbelt wrote:
> 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.

Ok, I just wanted to know if this was intentional or some sort of a bug.

Some way to disable the default multilib would be nice in general. 
Ending up with the default multilib usually indicates some build system 
misconfiguration. It is not easy for the average user to figure out what 
is going on especially on targets where the linker silently links ABI 
incompatible objects together.

>
>>> 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/

I will probably add a special multilib set for RTEMS.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.