<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-28 21:32 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 11:22 pm, Peng Fan wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
Hi,<br>
<br>
<br>
2014-07-28 9:13 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 28/07/2014 12:01 am, Peng Fan wrote:<br>
<br>
        Sorry. The patch is in the attachment. Missed it just now.<br>
<br>
<br>
    The patch looks fine and it is nice solution. Maybe the RTL parts<br></div>
    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><br>
    <<a href="http://git.rtems.org/chrisj/rtems_waf.git" target="_blank">http://git.rtems.org/chrisj/<u></u>rtems_waf.git</a>> repo and the rtl.git<div class=""><br>
    repo made to reference this repo. The examples-v2 repo does this<br>
    now. Are you able to look into this for me ?<br>
<br>
You mean using waf to compile rtems applications? Yeah, I saw<br>
examples-v2 use waf wscript.<br>
<br>
Why merge RTL to rtems_waf.git? Provide a more convinent way to let user<br>
use RTL?<br>
I am glad if I can do something. Before that I prefer your advice :).<br>
</div></blockquote>
<br>
I mean merge the RTL support in the rtems.py file to the rtems_waf.git repo.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
<br>
<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>
        <mailto:<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> <mailto:<a href="mailto:van.freenix@gmail.com" target="_blank">van.freenix@gmail.com</a>><u></u>>__>:<div class="">
<br>
<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>
        <mailto:<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> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>>>:<div class=""><br>
<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>
<br></div>
        /opt/rtems-4.11/arm-rtems4.11/<u></u>____realview_pbx_a9_qemu/lib<div><div class="h5"><br>
<br>
                     --lib m --lib<br>
                     rtemscpu --lib rtemsbsp --base rtld.prelink --entry<br>
          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<br>
        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<br>
        and that<br>
                 RAP pulls the same code in from one of those libraries<br>
        it will<br>
                 not be linked to. Rather the first instance of the code<br>
        loaded<br>
                 is used. The downside is a possible waste of code.<br>
<br>
             Yeah.Other RAP file which references the same code that<br>
        already in<br>
             the first rap should not pull the same code into the final<br>
        image.<br>
<br>
<br>
                 I suppose we could add code to compact the memory and<br>
        not loaded<br>
                 the object file and so the overhead is limited to the<br>
        RAP file.<br>
<br>
             Sorry. I can not got this. what code should be added to<br>
        rtl-host?<br>
<br>
<br>
    Thinking about this some more I can understand why you did not get<br>
    it and also your question about host side is a good one. Thinking<br>
    out loud ...<br>
<br>
    Lets say we have RAP module A and B and both reference<br></div></div>
    'rtems_rate_monotonic_get___<u></u>status' which is not resident in the<div class=""><br>
    base kernel image. Both RAP modules will get a copy of the object<br>
    file. We load A first and it's copy is fixed up and<br></div>
    'rtems_rate_monotonic_get___<u></u>status' is placed in the global symbol<div class=""><br>
    table. Any other global symbols in that object file are also placed<br>
    in the global symbol table. Then we load B and we see<br></div>
    'rtems_rate_monotonic_get___<u></u>status' is present in the global symbol<div class=""><br>
    table. I suspect a duplicate symbol error is raised because we<br>
    currently do not know if both versions of the symbol match the same<br>
    code. I suppose a CRC16 could be added to the object file's data and<br>
    if A and B's versions match we ignore B's and the global symbols can<br>
    be referenced.<br>
<br>
    If we can determine the same is code is present I suspect removing<br>
    the unreferenced code in B at load time may be difficult on the<br>
    target because we have merged the object file's sections together<br>
    with all the other object files in the RAP file and may not have the<br>
    required info present to strip it out on target.<br>
<br>
    On the host side is the '--runtime-lib' (-P) option of rtems-ld<br>
    doing this anyway so why do we need to bother with the above ?<br>
<br>
Yeah. --runtime-lib handles the common code used by multiple RAP files.<br>
<br>
</div></blockquote>
<br>
Great.<div class=""><br>
<br>
<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.<br>
<br>
Hah! what kind of doc do you prefer? doxgen doc in patch format or just<br>
wiki?  And the documentation is about how to let user can easily<br>
integrate RTL into his/her application?<br>
</blockquote>
<br></div>
Yes, something about how to use the RTL, rtems-ld and what happens with applications.</blockquote><div>ok. I take time to update the wiki with what I have got. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Currently, I am more concerned about another problem which we talked<br>
about when I load python rap and you also talked about with sebh.<br>
lets say that we have a.o b.o c.o and the three .o files references<br>
symbols in libc.a libm.a librtemscpu.a librtemsbsp.a.<br>
Because libc.a libm.a librtemscpu.a librtemsbsp.a is not compile with<br>
-mlong-calls, so if the rap file is big enough, RTL target may fail to<br>
load the rap file since reloc entry from libxx.a is near jump, but dest<br>
symbol is in far away.<br>
</blockquote>
<br></div>
I remember but I am not sure of the detail any more. Does the gnu ld perform some sort of fix up when it does a static link ?<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is this is on the sparc target ?</blockquote><div>I only test it on ARM realview qemu platform.  I did not dig into bfd library, but i think ld can handle it using bfd lib.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am hacking it these few days, but still do not have a good idea,<br>
because it is hard to convert reloc entry in libxxx.a from near<br>
reference to far reference as '-mlong-call' does.<br>
</blockquote>
<br></div>
The RSB lets you add target specific options. I know it is hack but it might help. Check rtems/config/4.11/rtems-m32c.<u></u>bset for an example. Maybe you can add the -mlong-call to the sparc build to see what happens. </blockquote>
<div>using -mlong-call to compile rtems may only make librtemscpu.a and librtemsbsp.a not use relative reloc. To libc.a and libm.a and libgcc.a, it may not help.Hack rtl-host or ld bfd may help ,but may add arch sepecific code to rtl-host which is not a good idea. I'll try it on sparc sis.</div>
<div><br></div><div><br></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>