On 28/07/2014 11:22 pm, Peng Fan wrote:
Hi,
2014-07-28 9:13 GMT+08:00 Chris Johns <chr...@rtems.org
<mailto:chr...@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.free...@gmail.com
<mailto:van.free...@gmail.com>
<mailto:van.free...@gmail.com <mailto:van.free...@gmail.com>>__>:
Hi,
2014-07-26 9:28 GMT+08:00 Chris Johns <chr...@rtems.org
<mailto:chr...@rtems.org>
<mailto:chr...@rtems.org <mailto:chr...@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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
