Pass multiple same options to rtems_linkflags

[Chris Johns]

On 28/07/2014 11:22 pm, Peng Fan wrote:
> Hi,
>
>
> 2014-07-28 9:13 GMT+08:00 Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>>:
>
>     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
>     <http://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 ?
>
> You mean using waf to compile rtems applications? Yeah, I saw
> examples-v2 use waf wscript.
>
> Why merge RTL to rtems_waf.git? Provide a more convinent way to let user
> use RTL?
> I am glad if I can do something. Before that I prefer your advice :).

I mean merge the RTL support in the rtems.py file to the rtems_waf.git repo.

>
>
>
>
>         2014-07-27 22:00 GMT+08:00 Peng Fan <van.freenix at gmail.com
>         <mailto:van.freenix at gmail.com>
>         <mailto:van.freenix at gmail.com <mailto:van.freenix at gmail.com>>__>:
>
>
>              Hi,
>
>
>              2014-07-26 9:28 GMT+08:00 Chris Johns <chrisj at rtems.org
>         <mailto:chrisj at rtems.org>
>              <mailto:chrisj at rtems.org <mailto:chrisj at 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 ?
>
> Yeah. --runtime-lib handles the common code used by multiple RAP files.
>

Great.

>     We are in need of user documentation for the RTL code.
>
> 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?

Yes, something about how to use the RTL, rtems-ld and what happens with 
applications.

>
> Currently, I am more concerned about another problem which we talked
> about when I load python rap and you also talked about with sebh.
> 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.
> 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.

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 ?

Is this is on the sparc target ?

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

The RSB lets you add target specific options. I know it is hack but it 
might help. Check rtems/config/4.11/rtems-m32c.bset for an example. 
Maybe you can add the -mlong-call to the sparc build to see what happens.

Chris