Dynamic Object File Loading

[Chris Johns]

Joel Sherrill wrote:
> Chris Johns has been working on that. He is in Sidney and still asleep.
> The basics are working. He needs to update that page.

Sure. I can do that.

>  From what I know, more architectures need to be added for sure. And
> working on test coverage is important. There are likely features to be
> added.

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.

>
> One off-shoot idea we have had is that we think he has enough
> infrastructure to statically identify which methods in an executable
> are not referenced.
>

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.

> He needs to comment. :)

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.

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.

Chris