Pass multiple same options to rtems_linkflags

[Chris Johns]

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