<div dir="ltr">Hi,<div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-28 9:13 GMT+08:00 Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 28/07/2014 12:01 am, Peng Fan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sorry. The patch is in the attachment. Missed it just now.<br>
</blockquote>
<br></div>
The patch looks fine and it is nice solution. Maybe the RTL parts should be merged into the git://<a href="http://git.rtems.org/chrisj/rtems_waf.git" target="_blank">git.rtems.org/chrisj/<u></u>rtems_waf.git</a> 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 ?<br>
</blockquote><div>You mean using waf to compile rtems applications? Yeah, I saw examples-v2 use waf wscript. </div><div><br></div><div>Why merge RTL to rtems_waf.git? Provide a more convinent way to let user use RTL? </div>
<div>I am glad if I can do something. Before that I prefer your advice :). </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
<br>
2014-07-27 22:00 GMT+08:00 Peng Fan <<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a><br></div>
<mailto:<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>><u></u>>:<div class=""><br>
<br>
Hi,<br>
<br>
<br>
2014-07-26 9:28 GMT+08:00 Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a><br></div>
<mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>>:<div class=""><br>
<br>
On 26/07/2014 12:25 am, Peng Fan wrote:<br>
<br>
Hi Chris,<br>
<br>
I build a rap file using such a command :<br>
rtems-ld --lib-path<br></div>
/opt/rtems-4.11/arm-rtems4.11/<u></u>__realview_pbx_a9_qemu/lib<div class=""><br>
--lib m --lib<br>
rtemscpu --lib rtemsbsp --base rtld.prelink --entry rtems<br>
a.o b.o c.o<br>
*.o ...<br>
Is this ok? can reference a symbol in librtemscpu.a<br>
librtemsbsp.a? or<br>
the reference symbol from librtemscpu.a librtemsbsp.a should<br>
be included<br>
in the base image but not in the rap file?<br>
<br>
<br>
This is fine. You do not need to load a base image with<br>
everything you might need.<br>
<br>
If you create another RAP file and do the same thing and that<br>
RAP pulls the same code in from one of those libraries it will<br>
not be linked to. Rather the first instance of the code loaded<br>
is used. The downside is a possible waste of code.<br>
<br>
Yeah.Other RAP file which references the same code that already in<br>
the first rap should not pull the same code into the final image.<br>
<br>
<br>
I suppose we could add code to compact the memory and not loaded<br>
the object file and so the overhead is limited to the RAP file.<br>
<br>
Sorry. I can not got this. what code should be added to rtl-host?<br>
<br>
</div></blockquote>
<br>
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 ...<br>
<br>
Lets say we have RAP module A and B and both reference 'rtems_rate_monotonic_get_<u></u>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_<u></u>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_<u></u>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.<br>
<br>
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.<br>
<br>
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 ?<br>
<br></blockquote><div>Yeah. --runtime-lib handles the common code used by multiple RAP files. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We are in need of user documentation for the RTL code.</blockquote><div>Hah! what kind of doc do you prefer? doxgen doc in patch format or just wiki? And the documentation is about how to let user can easily integrate RTL into his/her application?</div>
<div><br></div><div>Currently, I am more concerned about another problem which we talked about when I load python rap and you also talked about with sebh.</div><div>lets say that we have a.o b.o c.o and the three .o files references symbols in libc.a libm.a librtemscpu.a librtemsbsp.a.</div>
<div>Because libc.a libm.a librtemscpu.a librtemsbsp.a is not compile with -mlong-calls, so if the rap file is big enough, RTL target may fail to load the rap file since reloc entry from libxx.a is near jump, but dest symbol is in far away.</div>
<div>I am hacking it these few days, but still do not have a good idea, because it is hard to convert reloc entry in libxxx.a from near reference to far reference as '-mlong-call' does.</div><div><br></div><div>Regards,</div>
<div>Peng.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Chris<br>
</font></span></blockquote></div><br></div></div>