<div dir="ltr">Thanks Dr Joel and Chris for replying.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 1:12 AM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Joel Sherrill wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Chris Johns has been working on that. He is in Sidney and still asleep.<br>
The basics are working. He needs to update that page.<br>
</blockquote>
<br></div>
Sure. I can do that.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 From what I know, more architectures need to be added for sure. And<br>
working on test coverage is important. There are likely features to be<br>
added.<br>
</blockquote>
<br></div>
Yes this is an important needed part of the project. Generating tests for this project is complicated by the multi-stage build and link processes needed to generate kernel symbols and then to have them present in the executable. Some targets have a suitable file system like i386 qemu which is easier to handle while others do not such as the SPARC SIS simulator. This means we need to handle the more complex case of no file system when testing. An internal tar file is no solution either because you need to link, get the symbols, add the symbols file to the tar file and then relink.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
One off-shoot idea we have had is that we think he has enough<br>
infrastructure to statically identify which methods in an executable<br>
are not referenced.<br>
<br>
</blockquote>
<br></div>
This is more of an RTEMS Tools project than an RTL project but I am happy to have it come under the RTL project's control. The RTEMS Linker uses a C++ framework to perform its tasks and this could be used to make this tool. The student would need to have a fair amount of C++ and STL experience to work with the RTEMS Tool C++ framework.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
He needs to comment. :)<br>
</blockquote>
<br></div>
Architecture and testing is a top priority and should be suitable for GSoC. The ARM architecture is a good example. I have code in the RTL project to support it but it needs testing. ARM has a range of relocation fix up records that need to be tested. I am not sure how you generate these record and if they are valid for RTEMS and the operating modes we support. Adding support for all architectures would be nice. These tasks are C and target based.<br>

<br></blockquote><div style>It would be great if there are references to your ARM RTL code. Also it would be great if you can tell me what ARM simulator do you use with RTEMS (and which BSP). I had a lot of troubles finding ARM simulators to work last year. Any further info/references will be great.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The project also has tasks related to management on the host of library based objects. For example you have an application that links to create module a.rap and another module that links to create b.rap and both use a common library function foo() from foo.o from libbar.a. The RTEMS linker (rtems-ld) needs a mode where foo.o is collected in to a "target library" and that library is viewable by rtems-ld when each module is linked. This avoids foo.o being linked into both applications. This task leads to another task of adding archive support for RAP format object files. Again these tasks require a good level of C++ and STL experience.<span class="HOEnZb"><font color="#888888"><br>

<br>
Chris<br>
</font></span></blockquote></div><br></div></div>