Rust for RTEMS [was: Re: Interested for GSoC 2023]

[Joel Sherrill]

On Mon, Feb 27, 2023 at 5:00 AM Karel Gardas <karel at functional.vision>
wrote:

>
> adjusting subject based on Jan request. Keeping whole Rust relevant
> comments in.
>
> On 2/27/23 11:07, Jan.Sommer at dlr.de wrote:
> >
> >
> >> -----Original Message-----
> >> From: devel <devel-bounces at rtems.org> On Behalf Of Karel Gardas
> >> Sent: Montag, 27. Februar 2023 09:16
> >> To: joel at rtems.org; Vihas Makwana <makvihas at gmail.com>
> >> Cc: rtems-devel at rtems.org <devel at rtems.org>
> >> Subject: Re: Interested for GSoC 2023
> >>
> >> On 2/27/23 02:16, Joel Sherrill wrote:
> >>> Another GCC related project could be Rust RTEMS Support but I don't
> >>> know what that entails beyond turning it on and seeing what goes
> >>> wrong. I tried to build it last year and got far enough to decide to
> >>> wait before trying again.
> >>
> >> Not sure how far you went. The process is generally:
> >>
> >> (1) tune Rust compiler to cross-compile correctly for specific
> hardware/os
> >> platform. So basically you get no_std capable compiler
>

You should be able to compile gcc rust NOW to target CPU-rtems. I would
expect minor tweaking of configuration both in configure scripting and
likely
in the Rust run-time libraries. For example, with the Standard C++ Library
there are configuration settings for *-rtems which pick the threading and
synchronization model. Rust's run-time adapter with GCC should be similar.


> >>
> >> (2) review, patch and by using (1) cross-compile libc
>

Not a huge deal since you can add Rust to a standard gcc build
by adding rust to the "--enable-languages" argument on configure.

It is basically a standard cross gcc-rtems build with rust added to
the languages.



> >>
> >> (3) using sources from (1) and (2) build full stage (std enabled) rustc.



> >>
> >> (4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth
> >> sharp edges for RTEMS.
>

Yep. May also uncover some small alligators in the standard Rust code which
is too Linux centric.


> >>
> >> Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not
> cortex-
> >> mX).
>

Is it using the "one tree" build and build the C library at the same time?

I attached my scripts to do this. Be warned they are what is jokingly
referred
to as "j scripts" which means they are helpers for me but not necessarily
for external human consumption. :)

Generally you will have to tweak them at the top for install point,
binutils and
gcc source tree name, etc. I generally:

+ clone binutils-gdb, newlib, and gcc
+ sym link newlib/newlib and newlib/libgloss into gcc's tree
+ run contrib/download_prerequesites in the top of gcc's source tree

j-bin gets you an install of binutils and gdb
j-gcc layers on gcc

You likely want to make sure the script --disable-multilib to speed up
the builds and work with an architecture/BSP where the default
multilib works together. sparc and aarch64 meet that rule. Building
the multlibs is time consuming and counterproductive when just
working through basic breakages.


> >>
> >
> > Hi Karel,
> >
> > Very interesting work. I am currently trying to reach the same goal.
> > The steps I came up with are a bit different:
> > A.) Build working llvm toolchain for RTEMS (figure out all flags etc.,
> maybe building RTEMS with llvm as a bonus)
> > B.) Build rustc with the "RTEMS-llvm" as backend
>
> Honestly I'm not so sure (A) and (B) are necessary for rustc port. Or
> perhaps I do not precisely follow what you mean, but IMHO what you need
> is to get ABI and linking with RTEMS binaries right. And this applies
> also to RTEMS being build by GCC toolchain. This is objective of my (1)
> work.
>
> > C.) Start with no_std and then inch forward to building the stdlib
> >
> > I work currently on step A (see my llvm experiments in the other thread)
> and started to look at the build stages for rustc.
> > If you have any tips for the configuration from your step (1), it would
> be greatly appreciated.
> > My hope is that with the results of step A I can reuse the libc from the
> standard rtems-gcc build environment as this is provided conveniently via
> rsb.
>
> Not sure if I did not confused you with my (2) libc remark. I of course
> mean Rust's libc (that means rust code) to be build on top of
> RTEMS/Newlib/libbsd combination. It'll be interesting project especially
> if the requirement later would be to support both binary targets: e.g.
> RTEMS without libbsd (for smaller systems) and RTEMS with libbsd for
> full-blown configuration. Anyway, for now, I would start with libbsd as
> this should make project proceeding faster IMHO.
>

You shouldn't need RTEMS or libbsd built until you link real executables
you want to run. All needed POSIX headers are present from newlib.

I was test building rust just like C, C++, and Ada. Build the toolchain and
then build RTEMS.

>
> > I am really looking forward to seeing rust supported on RTEMS.
>
> Me too!
>
> Karel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230227/cf5539c1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: j-bin
Type: application/octet-stream
Size: 1337 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230227/cf5539c1/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: j-gcc
Type: application/octet-stream
Size: 3097 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230227/cf5539c1/attachment-0001.obj>