Hi Joel:<br> In the last weekend i have investigated the open project "Build Rtems with Clang". I read the wiki link about this open project and <br>some patches for the LLVM/Clang, it seems that the Clang has a basic support for i386-rtems target. And then i clone the repository <br>
of LLVM/Clang, newlib, rtems and all related toolchains for build rtems. After build and install the LLVM/Clang-3.0, i build a test case <br>for target i386-rtems using Clang, it is OK. So i patched the newlib patches and then build the newlib using Clang-3.0, but there are <br>
some coredump for Clang. The error log is blow:<br>----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
clang-3.0: /sdb1/LLVM/llvm-3.0.src/lib/Target/TargetData.cpp:401: uint64_t llvm::TargetData::getTypeSizeInBits(llvm::Type*) const: Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed.<br>
Stack dump:<br>0. Program arguments: /usr/local/bin/clang-3.0 -cc1 -triple i386--rtems4.11 -S -disable-free -disable-llvm-verifier -main-file-name regexec.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -momit-leaf-frame-pointer -g -coverage-file /tmp/regexec-GCwqS9.s -resource-dir /usr/local/bin/../lib/clang/3.0 -isystem /sdb1/rtems-llvm/newlib-rtems/build-1.20/i386-rtems4.11/newlib/targ-include -isystem /sdb1/rtems-llvm/newlib-rtems/newlib-1.20.0/newlib/libc/include -D PACKAGE_NAME="newlib" -D PACKAGE_TARNAME="newlib" -D PACKAGE_VERSION="1.20.0" -D PACKAGE_STRING="newlib 1.20.0" -D PACKAGE_BUGREPORT="" -D PACKAGE_URL="" -D _COMPILING_NEWLIB -D MALLOC_PROVIDED -D EXIT_PROVIDED -D SIGNAL_PROVIDED -D REENTRANT_SYSCALLS_PROVIDED -D HAVE_NANOSLEEP -D HAVE_BLKSIZE -D HAVE_FCNTL -D HAVE_ASSERT_FUNC -D _NO_GETLOGIN -D _NO_GETPWENT -D _NO_GETUT -D _NO_GETPASS -D _NO_SIGSET -D _NO_WORDEXP -D _NO_POPEN -D _GNU_SOURCE -I . -I ../../../../../newlib-1.20.0/newlib/libc/posix -fmodule-cache-path /var/tmp/clang-module-cache -O2 -ferror-limit 19 -fmessage-length 80 -fno-builtin -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/regexec-GCwqS9.s -x c ../../../../../newlib-1.20.0/newlib/libc/posix/regexec.c <br>
1. <eof> parser at end of file<br>2. Per-module optimization passes<br>3. Running pass 'CallGraph Pass Manager' on module '../../../../../newlib-1.20.0/newlib/libc/posix/regexec.c'.<br>4. Running pass 'Loop Pass Manager' on function '@regexec'<br>
5. Running pass 'Loop Invariant Code Motion' on basic block '%140'<br>clang-3: error: unable to execute command: Aborted (core dumped)<br>clang-3: error: clang frontend command failed due to signal 2 (use -v to see invocation)<br>
clang-3: note: diagnostic msg: Please submit a bug report to and include command line arguments and all diagnostic information.<br>clang-3: note: diagnostic msg: Preprocessed source(s) are located at:<br>clang-3: note: diagnostic msg: /tmp/regexec-82Lcft.i<br>
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>But when i copy the error build command to build the single regexec.c it is build successfully, Could you tell me why?<br>
And i think there are a lot of work to do to make LLVM/Clang support Rtems, like intergrate the LLVM/Clang into Rtems make system, <br>support more architectures using Clang build Rtems, and fix more bugs to make Clang build Rtems more stable like FreeBSD Clang project.<br>
Whether this project as a Gsoc project is suitable, Joel? Thank you!<br><br>WeiYang<br>Best Regards<br><br><div class="gmail_quote">在 2012年2月9日 下午11:10，Yang Wei <span dir="ltr"><<a href="mailto:wei.a.yang@gmail.com">wei.a.yang@gmail.com</a>></span>写道：<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF"><div><br></div><div>在 2012-2-9，6:03，Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>> 写道：<br>
<br></div><div class="im"><div></div><blockquote type="cite"><div>
<br>
<br>
On 02/07/2012 08:34 AM, yangwei weiyang wrote:
<blockquote type="cite"><font>Hi all:<br>
From the mail of Joel I know that the Google summer of code
2012 is going to start and RTEMS will be absolutely a member of
organizations. There are lots of projects i am interested in
from the Wiki open project section. The most favorite one for me
is "Bus Space API". So i want to know as much information as
possible.<br>
First i have read "Bus Space API" section carefully at the
Wiki, And also know some basic backgroud through the IRC log.
The bus_space API is originally from NetBSD, its goal is to
allow a single driver source file to manipulate a set of devices
on different system architectures, and to allow a single driver
object file to manipulate a set of devices on multiple bus types
on a single architecture. It is implemented in the BSP layer and
the architecture layer, that means different architecture and
machine must implement its own bus space type and <br>
functions. But the goal of "Bus Space API" project is to easing
the ports of BSD drivers to RTEMS, so in order to realize its
goal, should we port bus_space API to RTEMS BSP layer and
architecture layer or adapt the bus_space API in the RTEMS score
which make BSP layer and architecture layer unchanged or changed
minimum? <br>
So i want to know more information about this project, are
there some protential mentors to help me?<br>
</font></blockquote>
This is indeed an important project. Unfortunately, after discussing
it with another<br>
core developer, we think it may be beyond a GSOC project. <br>
<br>
First, it requires deep knowledge across RTEMS, boards, target
architectures, etc.<br>
We are afraid that by the time we mentored you enough to solve the
problem, <br>
(1) we could have implemented it and (2) the summer would be over.
:)<br>
<br>
Another factor is that a couple of the core developers are currently
<br>
supposed to be funded to do this as soon as they finish up another
project.<br>
Based on the schedule, they should be nearly finished before the
GSOC <br>
students accepted are announced. They are only committed to
implementing<br>
the BSP/target side of this for a couple of architectures.<br>
<br></div></blockquote></div>Joel, thank you for your suggest. One of goals of Gsoc project is to take the students into<div>the open source development, and another goal is to benefit the organization. So if this project</div>
<div><span>is too big to implement for students that it should be splitt<span>ed into some small parts or he will turn </span></span></div><div><span>to other projects.</span></div><div><div class="im"><blockquote type="cite">
<div>
This leaves you the option of proposing to implement this for the
remaining<br>
architectures. But it also puts you down stream of another schedule
which is<br>
a risk.<br>
<br>
I wouldn't want you to be at risk of even starting on time. Is there
another<br>
project you would like to do?<br></div></blockquote></div>Yes, except the Bus API project, I also have an interested project to participate in which is about</div><div>support the LLVM/Clang to Rtems. So i want to know how about the progress of this project and</div>
<div>whether this project is suitable as a Gsoc project?<br><blockquote type="cite"><div>
<blockquote type="cite"><font> <br>
Wei Yang<br>
Best Regards</font></blockquote></div></blockquote><br></div><div>Wei Yang</div><div>Best Regards</div></div></blockquote></div><br>