SOCIS 2013 - application

[Rempel, Cynthia]

Hi Marian Such,
Thanks for taking an interest in RTEMS!

>Yes, however, I would not be surprised if we hit numerous bugs (i.e. in multiarch support) along the way. My idea how to cope with that is that we can fill bug reports and even submit patches right away if the solutions are trivial. If the bugs are non-trivial, we should agree ad-hoc if it's better to workaround the bug or to solve it within clang. At least that's what I propose, but I'm open to other suggestions.

What are the problems with the current clang port that this project will solve? Why is this an improvement?

>MacOS support for gcc tools is provided by the RTEMS Source Builder (RSB). The details are ..
>http://www.rtems.org/ftp/pub/rtems/people/chrisj/source-builder/source-builder.html
>My idea was to provide pre-built package installer (.pkg) and maybe fink/macports packages.

What is the maintainence plan for the package installer?  What is the testing plan for the package installer?

The package installer must be capable of taking binaries built with RTEMS's preferred tool building script (RSB), so that when we RSB built packages, we are testing the binary packages as well.

Why not use a platform independent package installer written in python, like 0install http://0install.net/?

>>I would welcome support for clang. Is this enough for a SOCIS project ? If clang needs changes for RTEMS then this would start to look like a sizable task.
>Let's hope it won't grow out of proportions :)
Could we verify the RTEMS clang port doesn't work, and know the error messages?

>>Do we need a specific clang build for each RTEMS architecture ?
>First of all, clang currently supports only limited number of targets, see [1]. My suggestion is to complete full build for 1 platform first (x86 or ARM) and only after this focus on sparc and other platforms. It's quite improbable that clang will ever support all platforms supported by RTEMS, even though llvm has a nice list of supported architectures [2].

I would suggest the project consist of doing a port that hasn't been done already, or make hooking it into the RSB the goal...

>>Does clang handle the multilib configurations RTEMS needs ?
>In past two years there have been substantial work done on supporting multilib configurations but I have reasons to believe that it will not be flawless. I would suggest we also consider using ellcc [3].
This sounds new, and probably worth doing :)

>>Which backends are considered stable and worth looking at ?
>LLVM only.

>>>There are efforts underway for the Cortex-A9. This is happening in the xilinx-zynq bsps. This is a due core device so SMP is being worked on here. FYI I have OpenOCD working with the A9.
>>Nice. What is the current status of Cortex-A9 support?
Arm would probably be new, and worth doing...

>>Nice. I run MacOS and FreeBSD and keep the tools updated on both using the RSB. It is nice to see other MacOS users entering the community.

>Yep, OS X is solid system to work with. I wish RTEMS would provide binary tools packages for both OS X and Linux. I saw that some prebuilt packages were worked on during GSoC 2008. If the community decides on following up on this work, I will be happy to improve and automatize Linux prebuilt versions too. From what I've gathered, there is noone working on debian/ubuntu packages even though they are the most common distributions.

Again, I'd suggest just wrapping a package installer around binaries built by RTEMS supported tool building script RSB.  I would also suggest considering using one written in python, that's platform independent such as 0install, so a packager only has to learn one packaging tool, then run RSB on multiple build platforms in a VM. That way the packaging configurations will be maintained.