On 28/07/2014 12:01 am, Peng Fan wrote:
Sorry. The patch is in the attachment. Missed it just now.
The patch looks fine and it is nice solution. Maybe the RTL parts should be merged into the git://git.rtems.org/chrisj/rtems_waf.git repo and the rtl.git repo made to reference this repo. The examples-v2 repo does this now. Are you able to look into this for me ?
2014-07-27 22:00 GMT+08:00 Peng Fan <van.free...@gmail.com <mailto:van.free...@gmail.com>>: Hi, 2014-07-26 9:28 GMT+08:00 Chris Johns <chr...@rtems.org <mailto:chr...@rtems.org>>: On 26/07/2014 12:25 am, Peng Fan wrote: Hi Chris, I build a rap file using such a command : rtems-ld --lib-path /opt/rtems-4.11/arm-rtems4.11/__realview_pbx_a9_qemu/lib --lib m --lib rtemscpu --lib rtemsbsp --base rtld.prelink --entry rtems a.o b.o c.o *.o ... Is this ok? can reference a symbol in librtemscpu.a librtemsbsp.a? or the reference symbol from librtemscpu.a librtemsbsp.a should be included in the base image but not in the rap file? This is fine. You do not need to load a base image with everything you might need. If you create another RAP file and do the same thing and that RAP pulls the same code in from one of those libraries it will not be linked to. Rather the first instance of the code loaded is used. The downside is a possible waste of code. Yeah.Other RAP file which references the same code that already in the first rap should not pull the same code into the final image. I suppose we could add code to compact the memory and not loaded the object file and so the overhead is limited to the RAP file. Sorry. I can not got this. what code should be added to rtl-host?
Thinking about this some more I can understand why you did not get it and also your question about host side is a good one. Thinking out loud ...
Lets say we have RAP module A and B and both reference 'rtems_rate_monotonic_get_status' which is not resident in the base kernel image. Both RAP modules will get a copy of the object file. We load A first and it's copy is fixed up and 'rtems_rate_monotonic_get_status' is placed in the global symbol table. Any other global symbols in that object file are also placed in the global symbol table. Then we load B and we see 'rtems_rate_monotonic_get_status' is present in the global symbol table. I suspect a duplicate symbol error is raised because we currently do not know if both versions of the symbol match the same code. I suppose a CRC16 could be added to the object file's data and if A and B's versions match we ignore B's and the global symbols can be referenced.
If we can determine the same is code is present I suspect removing the unreferenced code in B at load time may be difficult on the target because we have merged the object file's sections together with all the other object files in the RAP file and may not have the required info present to strip it out on target.
On the host side is the '--runtime-lib' (-P) option of rtems-ld doing this anyway so why do we need to bother with the above ?
We are in need of user documentation for the RTL code. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel