rv32ec-ilp32e not included in multilib

[nakane1chome]

Using the --enable-multilib for riscv-gnu-toolchain configure script does not compile the rv32ec/ilp32e libraries. It seems the files in riscv-gcc/gcc/config/riscv (t-rtems, t-elf-multilib) does not include this architecture.

[kito-cheng]

I've a personal TODO list is add implement --with-multilib-list= to select which arch/abi combination* would be included into mulit-lib lists, it can prevent change any line of source code in GCC to set that.

• e.g: --with-multilib-list=rv32ec/ilp32e,rv32e/ilp32e,rv32ic/ilp32i,rv32i/ilp32i

@jim-wilson any comment for this idea?

[ilg-ul]

The more you encourage people to use the experimental ilp32e, the more problems when the specs will be finalized, probably after the expected EABI.

[jim-wilson]

@philmulholland RISC-V is a open ISA, with lots of extensions available, and more expected in the future, which means that there are potentially an infinite number of possible multilibs. We will never be able to support them all by default. I have no interest in extending the current multilib list. If you want a different multilib list, you can make your own local modifications to get the multilib list you need. Multiple companies have already done this.

If you look at gcc/config/riscv/t-elf-multilib you can see that it was generated by a script, with the command to generate it in comments. You can rerun the script with the options you want to get an updated list.

If you want this to work inside riscv-gnu-toolchain, then you will also need some changes there. You can see an example of how I did this for a few new multilibs in the sifive/riscv-gnu-toolchain multilib-patches branch.

[jim-wilson]

@kito-cheng We already have --with-multilib-list support in the FSF GCC tree. This was necessary to fix a linux native gcc install problem. glibc assumes libraries are in ABI specific dirs, which gcc will only do if using a --enable-multilib build. But we can't do a linux native --enable-multilib build as we can't support the ilp32 ABI on a rv64 yet. So the solution was to add --with-multilib-list support that you can do an --enable-multilib build while using --with-multilib-list=lp64d to only enable one multilib. That gets gcc to installe libraries in the right dirs.

But there is a problem here. When I wrote this I discovered that getting everything set to the right values turns out to be really complicated. I had to write some complicated shell script stuff to make this work, and I'm only supporting one ABI at the moment. I think that you will find that using --with-multilib-list this way is going to be impractical.

[jim-wilson]

@ilg-ul RV32E exists today, so we must have an ABI to support it today. Eventually the EABI will be defined to provide a better ABI for RV32E, but meanwhile we have ilp32e, and it isn't going away. If you don't like it, you don't personally have to use it or support it. But telling people that they need to wait a year or two before they can program a RV32E machine isn't practical, and thus we need to accept that for now ilp32e is the answer.

[ilg-ul]

But telling people that they need to wait a year or two before they can program a RV32E machine isn't practical

My expectations are that the RV32E ABI will be a subset of the EABI, i.e. the same functionality, just with less registers, which will probably require changes to ilp32e.

My concern is that when those changes will be discussed, there might be some users unhappy with an incompatible ABI change, and this might slow down the EABI process.

Apart from this, sure, those who need RV32E today are free to use it; my point is that we must help them be aware of future changes.

[kito-cheng]

@jim-wilson Oh, I didn't consider the path problem too much since it doesn't matter for bare-mental toolchain, but I know it's really big problem for Linux toolchain.

However I think linux and bare-mental toolchain have different scenario, maybe we can using different way to handle --with-multilib-list between those two type of toolchain?

[jim-wilson]

@kito-cheng Maybe. I haven't looked at using --with-multilib-list for embedded targets. You are welcome to take a look, but I suspect you will run into the same problems I did. You can't just give a list of arches or abis, you have to match compatible arches and abis. You have to handle aliasing like g and imafd. If you have more than a couple of choices it can get complicated pretty quickly.

[nakane1chome]

Hi @jim-wilson, no worries - understood. I raised the issue just in case the update of multilib had been overlooked when the rv32e support was added. However, I appreciate every extension cannot be supported.

Hi @kito-cheng For my use case--with-multilib-list= would be the ideal solution .

[billasurendra]

What I have to add in --with-multilib-list for supporting ARCH=rv64imafd