Dynamic Object File Loading

[Hesham Moustafa]

Thanks Dr Joel and Chris for replying.


On Wed, Mar 6, 2013 at 1:12 AM, Chris Johns <chrisj at rtems.org> wrote:

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130306/f3bd0aff/attachment-0001.html>