[PATCH v1 0/2] RISC-V: enable rust

[Conor Dooley]

On Mon, Apr 03, 2023 at 06:35:45PM +0200, Miguel Ojeda wrote:
> On Thu, Mar 30, 2023 at 11:12 AM Conor Dooley
> <conor.dooley at microchip.com> wrote:
> >
> > I'd rather do this in the RISC-V Makefile so that it does not get
> > forgotten.
> 
> Sounds good to me! We want to have the least amount of things possible
> in the common pieces (e.g. for the target spec file we moved some
> flags); so the more we move out to `arch/`, the better.
> 
> > If my understanding of bindgen is correct, we don't actually need to be
> > honest to it about what extensions the rest of the kernel is compiled
> > with, only make sure that it is not called with arguments it does not
> > understand?
> 
> As long as bindgen generates things with the right ABI etc., yeah.
> But, in principle, enabling one extension one side but not the other
> could be wrong if it ends up in something that Rust uses, e.g. if the
> C side does:
> 
>     #ifdef __ARM_ARCH_7R__
>         int x;
>     #else
>         char x;
>     #endif
> 
> and Rust attempts to use it, then particular `-march` builds could be broken.

To be on the safe side then, we should really disable the extensions
across the whole kernel. I don't *think* we have any madness at the
moment like in the above, but it is better to be on the safe side.
As I note below, it's just one extension for now anyway.

> > What version of GCC do I need to replicate this? I can build tip-of-tree
> > gcc if needs be.
> 
> Sorry, what do you want to replicate? If you mean what we had in the
> old GitHub CI, I see:
> 
>     CONFIG_CC_VERSION_TEXT="riscv64-linux-gnu-gcc (Ubuntu
> 11.3.0-1ubuntu1~22.04) 11.3.0"
> 
> which successfully boots in QEMU for the kernel config we tested.

No, I misunderstood your question. I thought you meant something else
entirely.

> But if you are asking what should be supported, I guess it depends on
> the RISC-V maintainers. Ideally, everything that the kernel supports
> (GCC >= 5.1),

Heh, as if that number is true across the board!

> but since the GCC+Rust builds are so experimental, I
> think as long as something is tested from time to time, it would be
> great (to at least know not everything is completely broken).
> 
> But if you think that would be too much effort to maintain, or even
> GCC builds in general, then please feel free to ignore it for the time
> being, i.e. it is better to have LLVM builds rather than nothing! :)

Yeah, it may be worth getting just the LLVM bits in. I abhor the -march
handling and it may end up looking like shite with the zicsr &
zifencei handling.
Worst comes to worst, can permit gcc builds by just removing all the
extensions that get passed in -march for RUST && CC_IS_GCC type
scenarios. The only one of those at the moment is zihintpause & I don't
suppose too many tears will be shed over that.
For now it's safe to assume that LLVM doesn't require zicsr or zifencei
[1], we don't need to do a version dance right away.

¯\_(ツ)_/¯,
Conor.

1 - https://reviews.llvm.org/D147183#4233360
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20230403/7d102d63/attachment.sig>