SOCIS 2013 - application

[Chris Johns]

Marian Such wrote:
>
> My idea was to provide pre-built package installer (.pkg) and maybe
> fink/macports packages.
>

Someone years ago add packages to macports that where broken and now 
years later are completely useless. I attempted to get them removed to 
avoid us getting bug reports however the macports people refused. If 
this is the quality of ports in macports I would prefer not to use them 
and do not. I am sure some packages are well maintained, it is a 
question of which ones. The same happened with FreeBSD however we can 
get those removed. Having these ports available is nice while someone 
looks after them however they are become the projects problem when they 
do not.

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

When I looked at the bfin a couple of years ago it was not even close to 
usable. Being listed and being usable are different. As you suggest x86 
is a good base and then ARM.

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

ELLCC is not something I would consider using. I prefer RTEMS be as 
close to the clang sources and maintainers as possible. Also having a 
single executable for all architectures has its draw backs and the GCC 
model of a single executable per architecture has its advantages. It can 
be difficult to get a single set of source that has all bugs fixed for 
all architectures. The RSB allows each architecture to have different 
source as well as specific patches. If you look in the RTEMS git repo 
rtems-tools you will see the patches there.

Multilibs is very important and needs to be address before anything else.

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

I was using the gcc term, which means architecture. As discussed x86 and 
ARM.

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

The Cortex-A9 is working. Getting 2 A9s operating in SMP is getting 
close. We have some bugs related to design choices in RTEMS code that do 
not work in SMP mode. These relate to task variables and disabling 
preemption as a high level lock.

> Yep, OS X is solid system to work with. I wish RTEMS would provide
> binary tools packages for both OS X and Linux.

I prefer building from source.

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

The RTEMS project defines the tool set at the source level. You are most 
welcome to build, test and host packaged tools for the community. Having 
them hosted by the RTEMS is a different matter. That depends on you and 
your commitment.

Chris