SOCIS 2013 - application

[Marian Such]

On Aug 8, 2013, at 1:29 AM, Chris Johns <chrisj at rtems.org> wrote:

>> The ideas which I found most interesting on the "Open Projects" wiki
>> page are:
>> • Compiling RTEMS with CLANG. (see [2])
> 
> Having the code compile on clang would be welcome. I assume this aspect of the task would relate specifically to RTEMS code changes. Is this correct ?

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.


>> • Packaging RTEMS tools for Mac OS X (see [3])
> 
> 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.


> 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 :)


> 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].


> 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].


> 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?


>> However, I
>> think it's not possible for one person to do such port in so short time,
>> so I would work on this only if I was to be a part of a team.
>> 
>> Regarding the CLANG and RTEMS tools on Mac, I feel confident this is
>> doable by one person and within the given time schedule. I own 3 macs,
>> on which I run 10.6, 10.7 and 10.8 OS X versions for development purposes.
>> 
> 
> 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.

cheers
Marian

[1] http://clang.llvm.org/docs/UsersManual.html#target-specific-features-and-limitations
[2] http://paste.lisp.org/display/138385
[3] http://ellcc.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130808/a2b7ba85/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130808/a2b7ba85/attachment.bin>