Pass multiple same options to rtems_linkflags

Peng Fan van.freenix at gmail.com
Mon Jul 28 14:15:25 UTC 2014


2014-07-28 21:32 GMT+08:00 Chris Johns <chrisj at rtems.org>:

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

ok. I take time to update the wiki with what I have got.

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

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

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.



>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140728/95718fc7/attachment-0002.html>


More information about the devel mailing list