<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 27, 2023 at 5:00 AM Karel Gardas <karel@functional.vision> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
adjusting subject based on Jan request. Keeping whole Rust relevant <br>
comments in.<br>
<br>
On 2/27/23 11:07, <a href="mailto:Jan.Sommer@dlr.de" target="_blank">Jan.Sommer@dlr.de</a> wrote:<br>
> <br>
> <br>
>> -----Original Message-----<br>
>> From: devel <<a href="mailto:devel-bounces@rtems.org" target="_blank">devel-bounces@rtems.org</a>> On Behalf Of Karel Gardas<br>
>> Sent: Montag, 27. Februar 2023 09:16<br>
>> To: <a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>; Vihas Makwana <<a href="mailto:makvihas@gmail.com" target="_blank">makvihas@gmail.com</a>><br>
>> Cc: <a href="mailto:rtems-devel@rtems.org" target="_blank">rtems-devel@rtems.org</a> <<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
>> Subject: Re: Interested for GSoC 2023<br>
>><br>
>> On 2/27/23 02:16, Joel Sherrill wrote:<br>
>>> Another GCC related project could be Rust RTEMS Support but I don't<br>
>>> know what that entails beyond turning it on and seeing what goes<br>
>>> wrong. I tried to build it last year and got far enough to decide to<br>
>>> wait before trying again.<br>
>><br>
>> Not sure how far you went. The process is generally:<br>
>><br>
>> (1) tune Rust compiler to cross-compile correctly for specific hardware/os<br>
>> platform. So basically you get no_std capable compiler<br></blockquote><div><br></div><div>You should be able to compile gcc rust NOW to target CPU-rtems. I would</div><div>expect minor tweaking of configuration both in configure scripting and likely</div><div>in the Rust run-time libraries. For example, with the Standard C++ Library</div><div>there are configuration settings for *-rtems which pick the threading and</div><div>synchronization model. Rust's run-time adapter with GCC should be similar.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>><br>
>> (2) review, patch and by using (1) cross-compile libc<br></blockquote><div><br></div><div>Not a huge deal since you can add Rust to a standard gcc build</div><div>by adding rust to the "--enable-languages" argument on configure.</div><div><br></div><div>It is basically a standard cross gcc-rtems build with rust added to</div><div>the languages. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>><br>
>> (3) using sources from (1) and (2) build full stage (std enabled) rustc.</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>><br>
>> (4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth<br>
>> sharp edges for RTEMS.<br></blockquote><div><br></div><div>Yep. May also uncover some small alligators in the standard Rust code which</div><div>is too Linux centric.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>><br>
>> Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not cortex-<br>
>> mX).<br></blockquote><div><br></div><div>Is it using the "one tree" build and build the C library at the same time?</div><div><br></div><div>I attached my scripts to do this. Be warned they are what is jokingly referred</div><div>to as "j scripts" which means they are helpers for me but not necessarily</div><div>for external human consumption. :) </div><div><br></div><div>Generally you will have to tweak them at the top for install point, binutils and</div><div>gcc source tree name, etc. I generally:</div><div><br></div><div>+ clone binutils-gdb, newlib, and gcc<br></div><div>+ sym link newlib/newlib and newlib/libgloss into gcc's tree<br></div><div>+ run contrib/download_prerequesites in the top of gcc's source tree<br></div><div><br></div><div>j-bin gets you an install of binutils and gdb</div><div>j-gcc layers on gcc</div><div><br></div><div>You likely want to make sure the script --disable-multilib to speed up</div><div>the builds and work with an architecture/BSP where the default </div><div>multilib works together. sparc and aarch64 meet that rule. Building</div><div>the multlibs is time consuming and counterproductive when just</div><div>working through basic breakages.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>><br>
> <br>
> Hi Karel,<br>
> <br>
> Very interesting work. I am currently trying to reach the same goal.<br>
> The steps I came up with are a bit different:<br>
> A.) Build working llvm toolchain for RTEMS (figure out all flags etc., maybe building RTEMS with llvm as a bonus)<br>
> B.) Build rustc with the "RTEMS-llvm" as backend<br>
<br>
Honestly I'm not so sure (A) and (B) are necessary for rustc port. Or <br>
perhaps I do not precisely follow what you mean, but IMHO what you need <br>
is to get ABI and linking with RTEMS binaries right. And this applies <br>
also to RTEMS being build by GCC toolchain. This is objective of my (1) <br>
work.<br>
<br>
> C.) Start with no_std and then inch forward to building the stdlib<br>
> <br>
> I work currently on step A (see my llvm experiments in the other thread) and started to look at the build stages for rustc.<br>
> If you have any tips for the configuration from your step (1), it would be greatly appreciated.<br>
> 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.<br>
<br>
Not sure if I did not confused you with my (2) libc remark. I of course <br>
mean Rust's libc (that means rust code) to be build on top of <br>
RTEMS/Newlib/libbsd combination. It'll be interesting project especially <br>
if the requirement later would be to support both binary targets: e.g. <br>
RTEMS without libbsd (for smaller systems) and RTEMS with libbsd for <br>
full-blown configuration. Anyway, for now, I would start with libbsd as <br>
this should make project proceeding faster IMHO.<br></blockquote><div><br></div><div>You shouldn't need RTEMS or libbsd built until you link real executables</div><div>you want to run. All needed POSIX headers are present from newlib.</div><div><br></div><div>I was test building rust just like C, C++, and Ada. Build the toolchain and</div><div>then build RTEMS.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I am really looking forward to seeing rust supported on RTEMS.<br>
<br>
Me too!<br>
<br>
Karel<br>
<br>
</blockquote></div></div>