Re: Pass multiple same options to rtems_linkflags
Hi, 2014-07-26 9:28 GMT+08:00 Chris Johns 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? I set rtems_linkflags like this: rtems_linkflags = ['--base', 'rtld.prelink', '--lib-path', '/opt/rtems-4.11/arm-rtems4.11/realview_pbx_a9_qemu/lib', '--entry', 'my_main', '--lib', 'm', '--lib', 'rtemscpu' , '--lib', 'rtemsbsp'], But waf only uses one '--lib', it removes the other two '--lib', like this: xxx '--entry', 'my_main', '--lib', 'm', 'rtemscpu', 'rtemsbsp',xxx I am not familar with waf, any advice about his? Try using LIBS and adding to that. Getting the order correct can be tricky. To bld whose feature is 'c program', libs = ['m', 'xxx'] works. But to 'c rap' which is defined in RTL, adding libs to bld of waf does not work. So I wrote a patch to fix this, the patch first clear the RTEMS_LINKFLAGS env, then refill it. The patch is in the attachments. Regards, Peng. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Pass multiple same options to rtems_linkflags
Sorry. The patch is in the attachment. Missed it just now. 2014-07-27 22:00 GMT+08:00 Peng Fan van.free...@gmail.com: Hi, 2014-07-26 9:28 GMT+08:00 Chris Johns 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? I set rtems_linkflags like this: rtems_linkflags = ['--base', 'rtld.prelink', '--lib-path', '/opt/rtems-4.11/arm-rtems4.11/realview_pbx_a9_qemu/lib', '--entry', 'my_main', '--lib', 'm', '--lib', 'rtemscpu' , '--lib', 'rtemsbsp'], But waf only uses one '--lib', it removes the other two '--lib', like this: xxx '--entry', 'my_main', '--lib', 'm', 'rtemscpu', 'rtemsbsp',xxx I am not familar with waf, any advice about his? Try using LIBS and adding to that. Getting the order correct can be tricky. To bld whose feature is 'c program', libs = ['m', 'xxx'] works. But to 'c rap' which is defined in RTL, adding libs to bld of waf does not work. So I wrote a patch to fix this, the patch first clear the RTEMS_LINKFLAGS env, then refill it. The patch is in the attachments. Regards, Peng. Chris 0001-Fix-multiple-same-options-in-rtems_linkflags-problem.patch Description: Binary data ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] RTEMS thread model configuration
On 26/07/2014 9:01 pm, Sebastian Huber wrote:
The command line to build a GCC for RTEMS contained virtually always a
'--enable-threads'. This patch helps to avoid this extra configuration
command line parameter and makes the GCC build a bit more user friendly
for RTEMS.
+1
This patch should be applied to GCC 4.9 branch and master.
2014-04-18 Sebastian Huber sebastian.hu...@embedded-brains.de
* config.gcc (*-*-rtems*): Default to 'rtems' thread model.
Enable selection of 'posix' or no thread model.
---
gcc/config.gcc | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 9b6a5f3..6eefa53 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -791,7 +791,13 @@ case ${target} in
;;
*-*-rtems*)
case ${enable_threads} in
-yes) thread_file='rtems' ;;
+ | yes | rtems) thread_file='rtems' ;;
+posix) thread_file='posix' ;;
Hmm the posix model is a little tricky. It would be good if this was the
standard for RTEMS however we know there are issues and leaving it
available lets us test when the issues start to get worked on yet having
this available also implies it is available for use. I suppose it is ok
and anyone building the tools knows what they are doing or is using
something like the RSB.
Chris
+no) ;;
+*)
+ echo 'Unknown thread configuration for RTEMS'
+ exit 1
+ ;;
esac
tmake_file=${tmake_file} t-rtems
extra_options=${extra_options} rtems.opt
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Pass multiple same options to rtems_linkflags
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.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: 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
