Re: Adding capture support to score
On 10/07/2014 6:09 pm, Sebastian Huber wrote: Hello Jennifer, I am about to go on vacation so I can only give some short comments. Have fun. This patch looks a bit like approach of the Timeline Tool from Edisoft: http://lists.rtems.org/pipermail/users/2007-October/017112.html I am more in favor of linker based versions like: http://www.rtems.org/wiki/index.php/RTEMS_Trace_Tool +1 What is missing is the context of the work being done. It would nice for Jennifer to update a wiki page with the requirements of the work, ie what functions need to be traced, SMP support etc. The trace tool approach documented in the wiki has 2 parts, the host side for generating the stubs and the target side for controlling, triggering and recording the events. The first part is complex and requires detailed analysis of the DWARF debug info to extract the function signature being wrapped [1]. The second part is a simpler and a more manageable task and I understand after a meeting with Joel and Jennifer this is the task being undertaken. The patch posted does not meet the trace tool end requirements and needs to be changed. It is too invasive. I am playing with a bit of C code locally to figure out a solution. I suspect it will be close to what is needed for the final solution however there maybe some extra defines in the RTEMS code to make it work. I am aiming for a 0 code change in the score however as stated I think this is not possible. The critical bit is the symbol name change for the function being traced, ie define a define. Another possible approach is to partially implement the host side based on a known list of function signatures. This would mean 0 changes to the score. This would be a nice solution. [1] I see this task being related to the RTL code base for the host tools. The host rtems-ld tool has a C++ framework for working with ELF files and it makes sense to add libdwarf support to this framework to support this work. http://en.wikipedia.org/wiki/DTrace This is describes the Linux approach: http://lwn.net/Articles/132196/ I have looked at both these are like them. Porting dtrace would be nice and Linux have nice frontends. I have played with dtrace but I have not being given the resources to fully look at this. The Illumos people would like to see us use it. No matter what we use in the end, I think its important that it can be disabled at compile-time (like profiling, debug, etc.). Fatal errors should result in _Terminate(). You can add a single trace point to this function. Logging the result can be done but then what. Everything has terminated and so there is no way we can extract the log with this event. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix RTL archive file load
On 14/07/2014 11:23 pm, Peng Fan wrote: When the first time executing such a command dlo libxx.ra:yy.rap or dlo libxx.a:yy.o, RTL complains no format loader found. when executing the command the second time, the archive files can be loaded correctly. It is because cache flush uses `file_size = -1` while file_size is unsigned type , and `rtems_rtl_obj_cache_read` should include a if condition because A cache obj can cache different files but it can only cache one file once. Hope this explaination is clear:) Details is in the patch. Applied. Thanks. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: nios2 build failure on RTEMS
On 17/07/2014 6:25 am, Joel Sherrill wrote: Hi sys/cdefs.h in the nios2 tools is too old to build the current RTEMS. Newer versions provide __DEVOLATILE Support is in 4.9.x but it is lacking the RTEMS specifics to allow us to built it. ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814: warning: implicit declaration of function '__DEVOLATILE' ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814: warning: nested extern declaration of '__DEVOLATILE' ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814: error: expected expression before 'void' ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814: warning: initialization makes pointer from integer without a cast ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c: In function 'dwmac_desc_enh_release_tx_bufs': ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:850: error: expected expression before 'void' ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:851: warning: passing argument 1 of 'memset' makes pointer from integer without a cast Can this code provide the macro is not present as a work around ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: GCC 4.9.1 Released
On 17/07/2014 12:46 am, Joel Sherrill wrote: Just passing along. Sebastian had two patches he wanted to see on the 4.9 branch and gcc head. Are there any others? What issues do we have moving to a 4.9.x release? I recall there being code generation issues but not the details. I think there are issues with 4.9.x. I have not tried all the targets we have so I do not know the pass/fail mix. I did try m32c with 4.9.0 and it does not build. The hacks to build 4.8.3 do not work on 4.9.0. This took up my time and I have not tried others. Chris Original Message Subject:GCC 4.9.1 Released Date: Wed, 16 Jul 2014 09:16:19 -0500 From: Jakub Jelinek ja...@redhat.com Reply-To: Jakub Jelinek ja...@redhat.com To: g...@gcc.gnu.org g...@gcc.gnu.org, gcc-annou...@gcc.gnu.org gcc-annou...@gcc.gnu.org, info-...@gnu.org info-...@gnu.org The GNU Compiler Collection version 4.9.1 has been released. GCC 4.9.1 is a bug-fix release from the GCC 4.9 branch containing important fixes for regressions and serious bugs in GCC 4.9.0 with more than 88 bugs fixed since the previous release. In addition to that, GCC 4.9.1 release supports OpenMP 4.0 also in Fortran, rather than just in C and C++. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: nios2 build failure on RTEMS
On 17/07/2014 8:47 am, Joel Sherrill wrote: On 7/16/2014 5:27 PM, Chris Johns wrote: On 17/07/2014 6:25 am, Joel Sherrill wrote: Hi sys/cdefs.h in the nios2 tools is too old to build the current RTEMS. Newer versions provide __DEVOLATILE Support is in 4.9.x but it is lacking the RTEMS specifics to allow us to built it. Which parts? Didn't we have these for the current configuration? Can't be very much. :) The current tools are the Altera versions that have been patched. Nothing could go upstream and there is only a tarball and no patch. I am sure they could be extracted and moved over. I do not have the time to do this and never bothered because nothing was broken until this driver. ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814: warning: implicit declaration of function '__DEVOLATILE' ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814: warning: nested extern declaration of '__DEVOLATILE' ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814: error: expected expression before 'void' ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814: warning: initialization makes pointer from integer without a cast ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c: In function 'dwmac_desc_enh_release_tx_bufs': ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:850: error: expected expression before 'void' ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:851: warning: passing argument 1 of 'memset' makes pointer from integer without a cast Can this code provide the macro is not present as a work around ? It could but I would rather not. It will end up being a permanent piece of code covering up a temporary problem. I see two options: + update the nios2 tools + provide a small patch to the nios2 tools to define this. I would prefer the 4.9.x path removing our dependence on the old Altera tools. Binutils is fine. I have used the latest with old gcc. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: capture engine use of workspace_allocate
On 22/07/2014 1:47 am, Joel Sherrill wrote: On July 21, 2014 10:44:15 AM CDT, Gedare Bloom ged...@rtems.org wrote: Either account for it in workspace sizing or use malloc. On principle, I guess any dynamic allocated memory that isn't mandatory to get RTEMS to work should come from malloc. With one malloc and two workspace allocates, I assumed we should use malloc for all three. This is too dynamic for the workspace IMO. I think the workspace was used because of allocations during a task start or context switch. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] RTL: Remove duplicated objects before writing to rap file for rtl-host
On 24/07/2014 5:04 pm, Peng Fan wrote: This patch fixes that before merging the objects to a rap file, first remove duplicated object files. When using STL unique, first should call STL sort method. Thanks and merged. Note, this fixes RAP format sizes as reported by a user with a LEON3 and RTEMS 4.10. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Zynq BSP
On 22/07/2014 1:00 am, emanuel stiebler wrote: On 2014-07-18 18:54, Chris Johns wrote: We still use the U-Boot to load it? I do not use uboot, rather we have a taken the Xilinx FSBL and reworked it. Could you at least share this part? And thanks for this already, I thought that I had to use u-boot. (which I don't mind, it just one more layer of work ;-) ) The code is based on Xilinx's FSBL and so I need to sort the licensing out before I can make it public. I would like to do a write up of the whole process but it is not a priority for my unfunded work. :( Do not be too unhappy, dealing with the licenses is taking my time and that is a good thing. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] capture: change to use malloc/vs/rtems_workspace_alloc.
On 24/07/2014 11:54 pm, Jennifer Averett wrote:
---
cpukit/libmisc/capture/capture.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/cpukit/libmisc/capture/capture.c b/cpukit/libmisc/capture/capture.c
index 9ec07b8..1fac4a0 100644
--- a/cpukit/libmisc/capture/capture.c
+++ b/cpukit/libmisc/capture/capture.c
@@ -339,9 +339,9 @@ rtems_capture_create_control (rtems_name name, rtems_id id)
This one is ok.
if (control == NULL)
{
-bool ok = rtems_workspace_allocate (sizeof (*control), (void **) control);
+control = malloc (sizeof (*control));
-if (!ok)
+if (control == NULL)
{
capture_flags |= RTEMS_CAPTURE_NO_MEMORY;
return NULL;
@@ -386,11 +386,10 @@ rtems_capture_create_capture_task (rtems_tcb* new_task)
rtems_capture_control_t* control;
rtems_name name;
rtems_capture_time_t time;
- bool ok;
- ok = rtems_workspace_allocate (sizeof (*task), (void **) task);
+ task = malloc (sizeof (*task));
Can malloc be called while in a user extension such as the context switch ?
Calls to this function happen during a context switch as the capture
engine discovers existing tasks.
When this code was written calling malloc crashed the target during a
context switch.
Chris
- if (!ok)
+ if (task == NULL)
{
capture_flags |= RTEMS_CAPTURE_NO_MEMORY;
return NULL;
@@ -480,7 +479,7 @@ rtems_capture_destroy_capture_task (rtems_capture_task_t*
task)
rtems_interrupt_lock_release (capture_lock, lock_context);
-rtems_workspace_free (task);
+free (task);
}
}
@@ -1027,7 +1026,7 @@ rtems_capture_close (void)
{
rtems_capture_task_t* delete = task;
task = task-forw;
-rtems_workspace_free (delete);
+free (delete);
}
capture_tasks = NULL;
@@ -1038,7 +1037,7 @@ rtems_capture_close (void)
{
rtems_capture_control_t* delete = control;
control = control-next;
-rtems_workspace_free (delete);
+free (delete);
}
capture_controls = NULL;
@@ -1216,7 +1215,7 @@ rtems_capture_watch_del (rtems_name name, rtems_id id)
rtems_interrupt_lock_release (capture_lock, lock_context);
- rtems_workspace_free (control);
+ free (control);
control = *prev_control;
___
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
Re: [PATCH] Fix headers and add RTC to altera-cyclone-v BSP.
On 28/07/2014 5:17 pm, Christian Mauderer wrote: just that there is no confusion about it: The second patch contains some large headers from the Altera hwlib. Therefore it is bigger than the maximum mail size for the list and has to be reviewed by a list administrator. Therefore it can need some additional time to turn up on the list. What is the license for these header files ? Are you able to post the license or is there a public reference to the code ? Did you obtain these files from an installed Altera tool or package with an EUL you accepted or via a login to Altera's website ? Please understand we cannot accept the code unless it is public or the project has an accepted agreement from Altera we can include it. Chris ___ 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 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
Re: [PATCH] Fix headers and add RTC to altera-cyclone-v BSP.
On 28/07/2014 6:43 pm, Christian Mauderer wrote: Am 28.07.2014 10:17, schrieb Chris Johns: On 28/07/2014 5:17 pm, Christian Mauderer wrote: just that there is no confusion about it: The second patch contains some large headers from the Altera hwlib. Therefore it is bigger than the maximum mail size for the list and has to be reviewed by a list administrator. Therefore it can need some additional time to turn up on the list. What is the license for these header files ? Are you able to post the license or is there a public reference to the code ? The license is the same like for the headers that are already included in this BSP in the hwlib directory. Altera uses a BSD-style license for the files from hwlib. It is written directly in the head of the headers and sources. Did you obtain these files from an installed Altera tool or package with an EUL you accepted or via a login to Altera's website ? The hwlib is packed with the Altera SoC Embedded Design Suite Web Edition. It is available here: http://dl.altera.com/soceds/?edition=subscription You have to register to get access to the installer. The complete pack has a number of different licenses for the different parts of the development environment. But the heads of the source files clearly state a BSD-style license for the hwlib part. I have confirmed with Altera the HWLIB is open source under a 3-clause BSD license and we can include it in our code base. Thanks must go to Altera for providing the code with a suitable license. Chris Please understand we cannot accept the code unless it is public or the project has an accepted agreement from Altera we can include it. Of course I understand that. It would be difficult to use RTEMS if you had to search every file for incompatible licenses. Kind regards Christian Mauderer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Pass multiple same options to rtems_linkflags
On 29/07/2014 12:15 am, Peng Fan wrote: 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. Thanks. 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. Ah ok ARM. 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, Using the RSB and the options I suggested rebuilds libc etc. It is still a bad hack. 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. Yeah it would be nice if rtems-ld could stay neutral but if it cannot then that is how it is. If we can keep the platform specific parts separate with a suitable class interface it should be ok. What would rtems-ld have to do on ARM to fix this problem ? I'll try it on sparc sis. Great. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/3] rbtree: Format
On 22/07/2014 11:38 pm, Gedare Bloom wrote: Thanks, I have added a section at http://www.rtems.org/wiki/index.php/Coding_Conventions#Tools and uploaded/linked to your configuration. Why not add to the source tree with a note ? Wiki pages are great if you know they exist !! Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RSB 0.4.0
Hi, I have pushed RSB 0.4.0. It contains the following: - GCC 4.8.3 targets are arm, avr, bfin, h8300, i386, m32c, m32r, m68k, microblaze, mips, moxie, powerpc, sh, sparc, sparc64. Newlib is CVS 26-Jul-2014. - GCC 4.9.1 targets are lm32, nios2. Newlib is CVS 26-Jul-201.4 - Show the download status when downloading. - Add checksum support for files. - ARM support for Cortex-M4 and Cortex-R based chips. - Add support for building 3rd Party packages for RTEMS. Add NTP and Net-SNMP as examples. With the checksum support if a file does not have checksum defined a warning message is generated. Please send me patches with the hash to help clean this up. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix headers and add RTC to altera-cyclone-v BSP.
On 29/07/2014 5:37 pm, Christian Mauderer wrote: After that problem is resolved, you can find the resubmission of the second patch as an answer to this mail. The original message has been approved. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Python RAP and Reloc related for RTL
On 4/08/2014 12:18 am, Peng Fan wrote: Hi, Create this new thread to talk about this topic and the reloc related. 1. As you suggested, I have compiled toolchain for arm using option `-mlong-calls` on arm realview qemu platform, and now the python.rap file can be correctly loaded and python interpreter can run the xxx.py in startup like this `rap ld ./python-library.rap tmp a.py`. Nice. How big is the RAP file ? Having to use the '-mlong-calls' option is hack. I think we need to teach the target code for ARM to add a veneer. Section 5.3.1.1 in http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf indicates this but does not seem to detail the process. I am not sure how this is actually done or what we are required to do. A small hack should be done is about gcc search dirs. I'll try to fix this later. What is the issue ? It would be good to have a record of it archived. Another issue is that, when python rap is loaded without and py file passed to it, it can not respond to input. The msg output is : RTEMS SHELL (Ver.1.0-FRC):/dev/console. Aug 3 2014. 'help' to list commands. [/] # rap ld ./python-library.rap rtl: loading './python-library.rap' rtl: rap: input machine=0 rtl: rap: machinetype=40 rtl: rap: datatype=1 rtl: rap: class=1 rtl: rap: input header=12 rtl: rap: load: symtab=16068 (1339) strtab=23867 relocs=0 rtl: rap: input .text=32948 rtl: rap: input .const=1088028 rtl: rap: input .data=1233652 rtl: rap: input symbols=1465241 rtl: rap: input relocs=1505176 Could not find platform independent libraries prefix Could not find platform dependent libraries exec_prefix Consider setting $PYTHONHOME to prefix[:exec_prefix] Python 2.7.8 (default, Aug 3 2014, 21:17:53) [GCC 4.8.3 20140522 (RTEMS 4.11-RSB-7c46699472b0d0adea2010f735722e2610c8c6ae-1, on linux2 Type help, copyright, credits or license for more information. It does not respond to input, any ideas about this? This looks like a qemu or BSP issue. Python expects some site specific python files. I cannot remember what this looks like for RTEMS. Maybe the old ftp tarball I once uploaded will give you an idea. If Python calling exit so halting the target ? 2. I have not tried on sparc sis, because it's memory is small. How to modify it's memory size in sis-gdb? I seem to remember an option you can provide with 'target sim'. Maybe a -? will provide some help. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RSB rtems-4.11 Tools for Windows.
Hi, The latest build of tools for Windows can be found here: http://www.rtems.org/ftp/pub/rtems/people/chrisj/source-builder/4.11/mingw32/latest/ All architectures are supported. On some architecture's gdb does not support the simulator option because of errors when building for Windows. The OpenRISC or1k-rtems4.11 tool set is provided for the first as a result of this years GSoC work by Hesham Moustafa's work. Thanks Hesham. I also provide all the source code used as a single tar file. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Using rtl-host in covor - some questions
Hi, Sorry about not responding before now. It had dropped of my list and I had forgotten about it. On 12/08/2014 9:58 pm, Krzysztof Mięsowicz wrote: Hi, I'm currently working on adding symbol generation to covoar. I'm going to use rtl::process::execute function to run nm from covoar (as suggested by Chris). I do not know exactly how should I use this in covoar. Should I build rtl-host as a library and link it to covoar? Or maybe there is another, better option? This is a really good question. Having covoar and rtems-host work together is a really thing because there is lots of good code to reuse. Currently the rtems-host repo is my private area and maybe this need to change. It is difficult to have both work together when in separate repos. Joel, should this code be moved to the rtems-tools.git repo ? As it stands rtems-host builds 3 static libraries and you can use those... $ ls build-linux2/*.a build-linux2/libelf.a build-linux2/libiberty.a build-linux2/librld.a Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Using rtl-host in covor - some questions
On 14/08/2014 7:34 am, Joel Sherrill wrote: On 8/13/2014 3:49 PM, Krzysztof Mięsowicz wrote: Hi, Thanks for your replies :-) I didn't see librld.a because I had old version of repo and after updating it appears :-) I think for now it would be better to get everything integrated with old nm-based approach. I had it working as a separate module, now I will integrate it into covoar. I think that one of next steps may be generating symbols without nm. There are two uses of symbols in covoar. The first is external and it is generating the symbols of interest for the run. That is currently a process that runs over the set of libraries of interest and lists all the text symbols in those libraries. Doing that with the Python based code should be a snap. What does run over a set of libraries mean ? We have a really good way to get at the symbols via C++ now with 0 parsing code or external tools. The other part is in covoar itself. As it processes each exe and builds the internal database of information, it needs the physical address of each method of interest in that particular exe. That is done by an invocation of nm with some magic processing afterwards. This could be done with libelf I think. The rtl-host is a wrapper to libelf which is included in the rtl-host code we are not dependent on host specifics or versions. But I also wonder if it would not be better to focus on changing flow of covoar - to avoid multiple runs (one for each symbol set as it would be now), because it takes quite long. I think it should be done in such way, that covoar reads symbol sets configuration file, runs analysis and takes data for all desired symbols from all sets and finally performs multiple reporting part, generating simple, generic output for each symbols set. Then covoar knows what purpose and scope of the reports are. As it stands now, covoar knows NOTHING about RTEMS. Let's keep it that way. Out of interest what is config file format for covoar ? I have added INI file support to the rtl-host repo and it seems stable and flexible. covoar gets slower as the set of symbols and tests grows. The standard run now already does at least two covoar runs. Once for all and one for core. The build and test execution time dominates. Where is bottleneck ? The RTL code uses an STL map for symbol look up. As we process smaller sets of symbols, covoar will be faster anyway. Besides, if it is slow enough, eventually we will profile and fix it. :) Another job I am thinking about doing next is adding more bsps support for coverage and getting things working on more bsps. This should be quite simple. This requires the simulator support. But you should be able to do arm and x86 with qemu. There is still one problem waiting for decision :-) What with rtems grub boot img for qemu? How should we integrate it into rtems-tools? Chris? Ah yes. I think we should download an image from a know spot but I have not looked into how to do this with the RSB. Maybe building grub from source is possible but that can be something for another day. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] RTL: Fix options handle and add a new option to rtems-ld
On 15/08/2014 7:37 pm, Peng Fan wrote:
On 08/15/2014 04:15 PM, Chris Johns wrote:
On 14/08/2014 11:21 am, Peng Fan wrote:
Hi,
I have a two days travel, so this reply is late.
2014-08-12 10:56 GMT+08:00 Chris Johns chr...@rtems.org
mailto:chr...@rtems.org:
On 11/08/2014 12:24 am, Peng Fan wrote:
1. Fix getopt_long usage in rtl host. some shorthand options
are not
hanlded correctly, this patch fixes it.
Thanks for cleaning this up.
2. Add a new option '--mach-flags'/'-m' to rtems-ld. This optarg
of this
option will be passed to xx-rtemsxx-gcc, it will be used the
search lib
dirs. Detailed msg is in the commit log of the patch.
I wonder if we need the explicit -march and -mcpu options and this
or should we remove them and add a more general option that can
include these flags. When I added the -march etc I thought this was
all that was needed and that is proving to be a little naive.
If -march and -mcpu are only passed to gcc to let gcc search the libs, I
think we can add a more generic option.
What do you think ?
I think we can extract the 'machine' related flags from rtems bsp and
build a table in rtl-host like the following:
struct bsp_flag {
char* bsp_name;
char* flags;
} ;
Here machine related flags in gcc is at
https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/ chapter 3.17.
struct bsp_flag bsp_flags[RTEMS_BSP_NUMS];
alloc space
bsp_flags[0].bsp_name = bsp name from rtems source code
bsp_flags[0].flags = machine flags from rtems source code corresponding
to the bsp
bsp_flags[1]
bsp_flags[2]
..
I think the user should manage this in their build environment. The
rtems-tld (trace linker) will need the BSP set up to work so this is a
different case.
I have not read related source code. what is it for?
The rtems-tld is a trace linker. It is still being worked on and not
usable. Trace linking lets a user define a set of functions they want to
trace and rtems-tld will generate the wrapping functions, compile them
and perform a link using the GNU ld's '--wrap=symbol' option. This will
combine with the capture engine to allow real-time tracing on targets.
The first pass of the rtems-tld will provide a proof of concept way to
output to stdout entry to a function with the arguments and the return
value shown as hex dumps. The capture engine integration is happening
slowly with Jennifer and is the end objective.
If things work out with rtems-tld the wrapping generators will be
specified in INI files which lets users provide custom ways to trace
execution. The INI files in the repo show the idea being worked on.
Using the machine flags, xxx_rtemsxx_gcc can search the related libs
first, if not found, then search the common libs, because the machine
related lib path is in the first.
Yes it can.
Just my thought, the code above is not good. Hmm. using String, new and
class in c++
I understand.
I think we may pass a madantory bsp name to rtl-host, such as --bsp
xxx , xxx means the bsp name
Or we pass --cc-flags and let the user manage the interface to the BSP.
If not pass correct machine flags to gcc, rtems-ld may link wrong
libgcc.a and other libxxx.a, and rtems-ld can not give any error msg
about this. At last, when loading rap file, error occurs, but hard to
find what happens.
I am not sure, but I think let user to handle the machine flags is not
user friendly, unless users are clearly about what machine flags should
be passed to xx-rtemsxx-gcc by rtems-ld.
If using --cc-flags, this option may be manatory, but not optional. And
the user should extract the machine flags from rtems source code.
I think passing bsp name to rtems-ld, and rtems-ld search a table which
contains bsps' name and the machine flags corresponding to the bsp. If
the bsp name passed to rtems-ld can not be found in the table, rtems-ld
complains err msg, If found, then all is fine.
This sounds reasonable. Maybe we provide both and users can decide. The
bsp option may be suitable and may need some extra options or they can
provide the full list and not specify a bsp.
Which ever way we go the rtems-ld and rtems-tld should be the similar.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] rtems: Add more clock tick functions
On 24/08/2014 6:57 pm, Sebastian Huber wrote: On 08/24/2014 05:02 AM, Chris Johns wrote: The calls names make sense from a programming point of view but from a user point of view they are sort of forwards and backwards. For example rtems_clock_ticks_later_us is the the clock tick so many micro-seconds later where later implies now or 'rtems_clock_tick_usecs_later' and following this I suppose 'rtems_clock_ticks_later' becomes 'rtems_clock_tick_ticks_later' ? What about rtems_clock_tick_later() and rtems_clock_tick_before()? In the context it should be clear what they do, e.g. Fine. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-tools and rtems-source-builder commit emails.
Hi, I have configured the rtems-tools and rtems-source-builder repos to send commit messages to the v...@rtems.org mailing list. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: BSP Build Failures Appeal
On 24/08/2014 7:59 pm, Pavel Pisa wrote: Hello Chris, On Sunday 24 of August 2014 05:33:45 Chris Johns wrote: On 23/08/2014 1:57 am, Joel Sherrill wrote: The build failures I reported were with the latest RSB tools Please pitch in and let's resolve them. I have a regression build that includes building all BSPs using ... $ rm -rf build rsb-report-* log_* ../source-builder/sb-set-builder --prefix=$HOME/development/rtems/4.11 --log=log_all_rtems --with-rtems --trace --regression 4.11/rtems-all ... running on sync.rtems.org as I am also seeing failures. This should give me a list of error reports with the first failure on an architecture. I left a similar build going for the weekend but using the head of gcc, newlib, and binutils. Hopefully the results are similar. Given the churn GSoC patches are creating I think we are still a while away from a freeze before release branching 4.11. I have fault with latest RTEMS git on tms570ls3137_hdk_intram tms570ls3137_hdk_sdram arm-lpc17xx_ea_ram arm-lpc40xx_ea_ram It is across most of the architectures including sparc without inspecting every error log. I expect that source of breakage is next commit score: Add SMP support to the cache manager http://git.rtems.org/rtems/commit/?id=ddbc3f8d83678313ca61d2936e6efd50b3e044b0 I agree. and the fact that CPU_INSTRUCTION_CACHE_ALIGNMENT does not get into defines for the most (or at least these without real cache) of ARM targets. Daniel(s) ?? May it be that some disable of SMP for CPUkit would help to these targets. But generally I am little afraid if cache management code does not cause overhead on systems without cache. In the theory there should be two builds of CPUkit for each multilib variant - one with SMP and another without if there is expected to build multiple BSPs against single CPUkit build. Yes in theory this is correct. The intention of the cpukit was to support multilib building of RTEMS and a binary compatible layer all BSPs could use however linkages to parts of the source outside of the cpukit from within it has meant this has never been cleanly implemented and I suspect never will nor worth further efforts. The other major contributing factor is the multilibs for gcc is subset of the multilibs for RTEMS because the same instruction set can execute on a range of differing cores exploding the build matrix. This means building RTEMS for a BSP is practical. As I understand that is used for distribution but not common for source users who build for single BSP usually. But should be checked by someone who knows RTEMS better than me. Multilib is not really used anywhere because of the complexities the configure options add. If you take ARM and it's increasing multilibs (gcc is taking a while to build on fast hardware these days) and then add the RTEMS number of specific variants and then multiple by the permutations of the configure options you have a massive build to support the distribution point of view. Then for a BSP you need to add on top of this BSPTOPS. So in theory each commit should run each of these variations for all BSPs to make sure nothing has broken however this is just not practical and that in my view means the way we handle configurations and variants is not sustainable and needs to change. Patches need to be checked for this before being pushed and even then breakages like this happen from time to time. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Adding eth linker script section for arm bsp.
On 27/08/2014 11:29 pm, Sebastian Huber wrote: On 27/08/14 15:18, Federico Casares wrote: diff --git a/c/src/lib/libbsp/arm/lpc176x/Makefile.am b/c/src/lib/libbsp/arm/lpc176x/Makefile.am index 3a1d4b2..36711a6 100644 --- a/c/src/lib/libbsp/arm/lpc176x/Makefile.am +++ b/c/src/lib/libbsp/arm/lpc176x/Makefile.am @@ -69,6 +69,7 @@ project_lib_DATA += startup/linkcmds EXTRA_DIST = EXTRA_DIST += startup/linkcmds.lpc1768_mbed EXTRA_DIST += startup/linkcmds.lpc1768_mbed_ahb_ram +EXTRA_DIST += startup/linkcmds.lpc1768_mbed_ahb_ram_eth Do you really need a lpc1768_mbed_ahb_ram and a lpc1768_mbed_ahb_ram_eth variant? The number of BSPs building for ARM has exploded and for just the ARM architecture there are now 27,417 tests built. If I could run each test in 20 seconds it would take over 6 days to do this. If I could run 6 tests in parallel it would still take 24 hours. I wonder how many of these variants have had all the tests run on them ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] preinstall: Regenerated files differ from the repo.
On 29/08/2014 12:30 am, Hesham Moustafa wrote:
On Thu, Aug 28, 2014 at 4:25 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
On 8/28/2014 9:20 AM, Hesham Moustafa wrote:
On Thu, Aug 28, 2014 at 4:12 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
Chris should be on a Mac. I am on Fedora 20.
I am on Fedora 20 too
$ autoconf --version
autoconf (GNU Autoconf) 2.69
The RSB version? 32 or 64 bit?
RTEMS Source Builder - Set Builder, v0.4.0
Python: 2.7.5 (default, Jun 25 2014, 10:19:55) [GCC 4.8.2 20131212
(Red Hat 4.8.2-7)]
Fedora 20 - 64 bit
Does the attached patch fix the problem ?
For me this patch gives the same output before Joel's patch (which may
need to be reverted).
Chris
From 93d0ddd41b6eec7e250eaad1f799cab6cdfb27f8 Mon Sep 17 00:00:00 2001
From: Chris Johns chr...@rtems.org
Date: Fri, 29 Aug 2014 11:39:29 +1000
Subject: [PATCH] bootstrap: Sort the various hash keys used in generating
preinstall.am.
Something must have changed in perl to change the way the keys are
ordered by default.
---
ampolish3 | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/ampolish3 b/ampolish3
index 69bbf7b..aaa9757 100755
--- a/ampolish3
+++ b/ampolish3
@@ -9,7 +9,7 @@
#
# Usage: ampolish3 Makefile.am preinstall.am
#
-# Reads a Makefile.am from stdin and writes corresponding
+# Reads a Makefile.am from stdin and writes corresponding
# pre/tmpinstall rules to stdout.
sub replace($);
@@ -85,7 +85,7 @@ foreach my $l ( @buffer1 ) {
push @buffer2, $l;
$dirmap{\$\($1\)} = replace($2);
} elsif ( $l =~ /^\s*noinst_(.*)\s*[\+]?\=(.*)$/o )
- {
+ {
#ignore: noinst_* are not relevant here.
} elsif ( $l =~
/^\s*(nodist_|dist_|)(project_|)([a-zA-Z0-9_]+)_(HEADERS|LIBRARIES|DATA|SCRIPTS|PROGRAMS)\s*([\+]?\=)\s*(.*)/o
)
{
@@ -217,7 +217,7 @@ $output .= \$(srcdir)/preinstall.am: Makefile.am\n;
$output .= \t\$(AMPOLISH3) \$(srcdir)/Makefile.am
\$(srcdir)/preinstall.am\n;
$output .= endif\n\n;
-foreach my $k ( keys %seen )
+foreach my $k ( sort keys %seen )
{
if ( $k =~ /PREINSTALL_FILES/o ) {
$output .= all-am: \$(PREINSTALL_FILES)\n\n;
@@ -258,7 +258,7 @@ exit 0;
sub replace($)
{
my ($v) = @_;
- foreach my $i ( keys %dirmap )
+ foreach my $i ( sort keys %dirmap )
{
$v =~ s/\Q$i/$dirmap{$i}/g;
}
--
1.8.5.2 (Apple Git-48)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB] [PATCH 1/2] Fix bug of uncompressing zip files.
On 29/08/2014 3:14 am, Hesham ALMatary wrote:
This patch uses __unzip macro for uncompressing zip files instead of
the wrong __zip macro which is not defined in defaults.mc file.
Merged. Thank you.
Chris
---
source-builder/sb/download.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/source-builder/sb/download.py b/source-builder/sb/download.py
index fbf9ce0..fdc834a 100644
--- a/source-builder/sb/download.py
+++ b/source-builder/sb/download.py
@@ -110,7 +110,7 @@ def _http_parser(source, config, opts):
source['compressed'] = '%{__bzip2} -dc'
elif esl[-1:][0] == 'zip':
source['compressed-type'] = 'zip'
-source['compressed'] = '%{__zip} -u'
+source['compressed'] = '%{__unzip} -u'
elif esl[-1:][0] == 'xz':
source['compressed-type'] = 'xz'
source['compressed'] = '%{__xz} -dc'
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB] [PATCH 2/2] Add support for building bare-metal or1ksim.
On 29/08/2014 3:14 am, Hesham ALMatary wrote: This patch adds support to enable RSB to build or1ksim emulator (the main OpenRISC 1000 simulator) from latest or1ksim github repo. Merged. Thanks. This is really great work. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] RTL: Fixed comparison of ELF object names
On 4/11/2013 1:01 pm, Mohammed Khoory wrote: Hi, While using RTL with ELF files, I noticed that if I load 2 ELF files via dlopen(), the first one loads correctly, but the second load call returns the same pointer to the first ELF handle. After looking a bit further I noticed that the ELF names weren't being compared properly when checking whether a particular ELF is already loaded or not. This patch fixes it by allowing the program to parse the filename properly before comparing it. There are many different approaches to fixing this, but with this patch I wanted to minimize code redundancy by reusing existing code. If I should take another approach please let me know. I have finally merged this change with a few minor changes. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: compile rtems source code error
On 3/09/2014 12:05 pm, 贾超 wrote: tools: sparc-rtems4.11. host: x86_64ubuntu. When I compile the source code in the sparc-rtems4.11 target, always appear the following error. ../../../sis/lib/include/rtems/rtems_bsdnet_internal.h:54:7: note: expected 'void *' but argument is of type 'volatile struct dwmac_desc_ext_erx *' ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c: In function 'dwmac_desc_enh_destroy_tx_desc': ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:3: warning: implicit declaration of function '__DEVOLATILE' [-Wimplicit-function-declaration] ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:3: warning: nested extern declaration of '__DEVOLATILE' [-Wnested-externs] ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:814:34: error: expected expression before 'void' ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c: In function 'dwmac_desc_enh_release_tx_bufs': ../../../../../rtems/c/src/libchip/network/dwmac-desc-enh.c:850:29: error: expected expression before 'void'. what cause this error? Your tool set. A change in newlib related to this patch fixes the issue ... https://sourceware.org/ml/newlib/2013/msg00250.html Sebastian's email provides a solution http://lists.rtems.org/pipermail/devel/2014-March/006265.html Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] or1k: Implement context validate and context volatile clobber functions.
On 3/09/2014 12:21 am, Joel Sherrill wrote: cpukit/score/cpu/or1k/preinstall.am|6 +- Did this patch happen before my fix to the preinstall went in ? I am seeing an issue with this one. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] capture: Split user extension methods out.
extension handlers for the CAPture Engine.
- */
- name = rtems_build_name ('C', 'A', 'P', 'E');
- sc = rtems_extension_create (name, capture_extensions, capture_id);
+ sc = rtems_capture_user_extension_open();
if (sc != RTEMS_SUCCESSFUL)
{
-capture_id = 0;
free (capture_records);
capture_records = NULL;
}
- else
- {
-capture_extension_index = rtems_object_id_get_index (capture_id);
- }
/*
* Iterate over the list of existing tasks.
@@ -1016,7 +670,7 @@ rtems_capture_close (void)
* release the resources we have without them being used.
*/
- sc = rtems_extension_delete (capture_id);
+ sc = rtems_capture_user_extension_close();
if (sc != RTEMS_SUCCESSFUL)
return sc;
diff --git a/cpukit/libmisc/capture/capture_user_extension.c
b/cpukit/libmisc/capture/capture_user_extension.c
new file mode 100644
index 000..f3bebc8
--- /dev/null
+++ b/cpukit/libmisc/capture/capture_user_extension.c
@@ -0,0 +1,435 @@
+/*
+
+
+ Copyright Objective Design Systems Pty Ltd, 2002
+ All rights reserved Objective Design Systems Pty Ltd, 2002
+ Chris Johns (c...@acm.org)
+
+ COPYRIGHT (c) 1989-2009.
+ On-Line Applications Research Corporation (OAR).
+
+ The license and distribution terms for this file may be
+ found in the file LICENSE in this distribution.
+
+ This software with is provided ``as is'' and with NO WARRANTY.
+
+
+
+ RTEMS Performance Monitoring and Measurement Framework.
+
+ This is the Capture Engine component.
+rtems_status_code rtems_capture_user_extension_open(void);
+rtems_status_code rtems_capture_user_extension_close(void);
+
+
+*/
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include stdlib.h
+#include string.h
+#include rtems/rtems/tasksimpl.h
+
+#include captureimpl.h
+
+#include rtems/score/statesimpl.h
+#include rtems/score/todimpl.h
+
+
+/*
+ * RTEMS Capture User Extension Data.
+ */
+static rtems_id capture_id;
+
+static bool
+rtems_capture_create_task (rtems_tcb* current_task,
+ rtems_tcb* new_task);
+
+static void
+rtems_capture_start_task (rtems_tcb* current_task,
+ rtems_tcb* started_task);
+
+static void
+rtems_capture_restart_task (rtems_tcb* current_task,
+rtems_tcb* restarted_task);
+
+static void
+rtems_capture_delete_task (rtems_tcb* current_task,
+ rtems_tcb* deleted_task);
+
+static void
+rtems_capture_switch_task (rtems_tcb* current_task,
+ rtems_tcb* heir_task);
+
+static void
+rtems_capture_begin_task (rtems_tcb* begin_task);
+
+static void
+rtems_capture_exitted_task (rtems_tcb* exitted_task);
+
+static void
+rtems_capture_terminated_task (rtems_tcb* terminated_task);
+
+static const rtems_extensions_table capture_extensions = {
+ .thread_create= rtems_capture_create_task,
+ .thread_start = rtems_capture_start_task,
+ .thread_restart = rtems_capture_restart_task,
+ .thread_delete= rtems_capture_delete_task,
+ .thread_switch= rtems_capture_switch_task,
+ .thread_begin = rtems_capture_begin_task,
+ .thread_exitted = rtems_capture_exitted_task,
+ .fatal= NULL,
+ .thread_terminate = rtems_capture_terminated_task
+};
+
+rtems_status_code rtems_capture_user_extension_open(void)
+{
+ rtems_status_code sc;
+ rtems_namename;
+ int index;
+
+ /*
+ * Register the user extension handlers for the CAPture Engine.
+ */
+ name = rtems_build_name ('C', 'A', 'P', 'E');
+ sc = rtems_extension_create (name, capture_extensions, capture_id);
+ if (sc != RTEMS_SUCCESSFUL)
+capture_id = 0;
+ else {
+index = rtems_object_id_get_index (capture_id);
+rtems_capture_set_extension_index( index );
+ }
+
+ return sc;
+}
+
+rtems_status_code rtems_capture_user_extension_close(void)
+{
+ rtems_status_code sc;
+ sc = rtems_extension_delete (capture_id);
+ return sc;
+}
+
+/*
+ * This function is called when a task is created.
+ */
+static bool
+rtems_capture_create_task (rtems_tcb* current_task,
+ rtems_tcb* new_task)
+{
+ rtems_capture_task_t* ct;
+ rtems_capture_task_t* nt;
+ int index = rtems_capture_get_extension_index();
+
+ ct = current_task-extensions[index];
+
+ /*
+ * The task pointers may not be known as the task may have
+ * been created before the capture engine was open. Add them.
+ */
+
+ if (ct == NULL)
+ct = rtems_capture_create_capture_task (current_task);
+
+ /*
+ * Create the new task's capture control block.
+ */
+ nt = rtems_capture_create_capture_task (new_task);
+
+ if (rtems_capture_trigger (ct, nt, RTEMS_CAPTURE_CREATE))
+ {
+rtems_capture_record (ct, RTEMS_CAPTURE_CREATED_BY_EVENT);
+rtems_capture_record (nt, RTEMS_CAPTURE_CREATED_EVENT
Re: OpenRISC/or1ksim RTEMS Tester results
On 7/09/2014 9:30 am, Joel Sherrill wrote: Not bad for a first run. :) Yeah nice work. I would love to commit a patch for this. Now look at timeouts and see if they can be addressed easily. May just need more run time. Or the failures? Timeouts can be tricky with different host and simulator speeds. I have not figured out a way to manage this in the tester cleanly. They could also be bugs. Chris On September 6, 2014 6:07:50 PM CDT, Hesham Moustafa heshamelmat...@gmail.com wrote: Hi all, Just want to share with you the results I got from running RTEMS Tester on or1ksim BSP and qemu. Passed: 356 Failed:13 Timeouts: 134 Invalid:0 Total:503 Average test time: 0:00:22.316492 Testing time : 3:07:05.195857 Regards, Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] [RTEMS TESTER] Add new OpenRISC/or1ksim BSP script using qemu
On 7/09/2014 4:25 pm, Hesham Moustafa wrote: The test results improved a little bit from yesterday. Here are the results: Passed: 365 Failed: 6 Timeouts: 130 Invalid:2 Total:503 Average test time: 0:00:22.877361 Testing time : 3:11:47.312905 The full log file is attached. If you run one of the timed out tests, say fsdosfsname01.exe from the command line does it complete and if so how long ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] RTL: Fix options handle and add a new option to rtems-ld
On 18/08/2014 12:17 am, Peng Fan wrote: 2014-08-16 10:51 GMT+08:00 Chris Johns chr...@rtems.org mailto:chr...@rtems.org: On 15/08/2014 7:37 pm, Peng Fan wrote: On 08/15/2014 04:15 PM, Chris Johns wrote: I think the user should manage this in their build environment. The rtems-tld (trace linker) will need the BSP set up to work so this is a different case. I have not read related source code. what is it for? The rtems-tld is a trace linker. It is still being worked on and not usable. Trace linking lets a user define a set of functions they want to trace and rtems-tld will generate the wrapping functions, compile them and perform a link using the GNU ld's '--wrap=symbol' option. This will combine with the capture engine to allow real-time tracing on targets. The first pass of the rtems-tld will provide a proof of concept way to output to stdout entry to a function with the arguments and the return value shown as hex dumps. The capture engine integration is happening slowly with Jennifer and is the end objective. If things work out with rtems-tld the wrapping generators will be specified in INI files which lets users provide custom ways to trace execution. The INI files in the repo show the idea being worked on. I tried rtems-tld and read about the verbose output msg from rtems-tld. Currently I found that it can only generate wrap functions. rtems-tld is to generate wrapping functions, compile the generated files with wrapping functions in it and other source files passed to rtems-tld using parameters, and link them using '--wrap-symbol'? is the final linked file is a rap file or others? is there a protocal between the capture engine and the wrapping functions? using serial to communicate? I just wonder this.:) The protocol is defined in configuration files. I have the trace linker building applications with wrapped function and I now need to add the code to generate the logging code based on the configuration to show it is working. My plan is let users play with this stuff in the examples-v2. Using the machine flags, xxx_rtemsxx_gcc can search the related libs first, if not found, then search the common libs, because the machine related lib path is in the first. Yes it can. Just my thought, the code above is not good. Hmm. using String, new and class in c++ I understand. I think we may pass a madantory bsp name to rtl-host, such as --bsp xxx , xxx means the bsp name Or we pass --cc-flags and let the user manage the interface to the BSP. If not pass correct machine flags to gcc, rtems-ld may link wrong libgcc.a and other libxxx.a, and rtems-ld can not give any error msg about this. At last, when loading rap file, error occurs, but hard to find what happens. I am not sure, but I think let user to handle the machine flags is not user friendly, unless users are clearly about what machine flags should be passed to xx-rtemsxx-gcc by rtems-ld. If using --cc-flags, this option may be manatory, but not optional. And the user should extract the machine flags from rtems source code. I think passing bsp name to rtems-ld, and rtems-ld search a table which contains bsps' name and the machine flags corresponding to the bsp. If the bsp name passed to rtems-ld can not be found in the table, rtems-ld complains err msg, If found, then all is fine. This sounds reasonable. Maybe we provide both and users can decide. The bsp option may be suitable and may need some extra options or they can provide the full list and not specify a bsp. 1. using a bsp option. extra options? I have added support for the arch/bsp and/or cflags with a default (path based) or user supplied compiler or linker (absolute paths). 2. they can provide the full list. You mean let user define the machine flags? like --machine-flags -mthumb -msoft-float -mxxx ? Anyway, I do not have enough experience. You decide. To me, I'd like to use a bsp option, and as u said users can also decide. I am newbie:) This is supported via the cflags options. Which ever way we go the rtems-ld and rtems-tld should be the similar. If the final image generated by rtems-tld is not a dynamically loadable elf/rap file, i think it is not needed to make rtems-tld have the same saying '--bsp' option with rtems-ld. Because the machine flags passed to xx-rtemsxx-gcc only affects the rap/elf dynamically loadable file. The rtems-tld currently has a little bit more code to set the compiler and linker
Re: [PATCH] RTL: Fix options handle and add a new option to rtems-ld
On 9/09/2014 12:32 am, Peng Fan wrote: 2014-09-08 14:16 GMT+08:00 Chris Johns chr...@rtems.org mailto:chr...@rtems.org: The rtems-tld currently has a little bit more code to set the compiler and linker. This is useful if you want to use absolute paths to the compiler and linker rather than depend on paths. I have made a number of changes and I have not tested rtems-ld. Are you able to run some tests on rtems-ld for me ? I tried rtems-ld to compile python.rap for arm realview_pbx_qemu_a9 bsp using such options: '-B arm/realview_pbx_qemu_a9 -r /opt/rtems-4.11' and rtems-ld can link the final rap image. At last when load the python.rap, the simpile xx.py file can be correctly executed. Yeah, I do some debug, and found that use '-B' can let gcc search the correct libs. I found that '-B' and '-r' should be set both, otherwise rtems-ld will complains errors 'No RTEMS path provide with arch/bsp'. I have just updated the code so the -r is only needed if rtems-ld is not installed. If installed giving it a valid prefix it will set the RTEMS path (-r) to the prefix. This means if you build RTEMS and install it and built the rtl-host code and installed it the paths will default to the $prefix. The test to determine the prefix is ok and not great but should work for standard installs. Anything else requires the -r option. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-tld tracing with printk
Hi, This is an update on the RTEMS trace linker being worked on and found in the http://git.rtems.org/chrisj/rtl-host.git repo. The following is a trace using the both_hello example in examples-v2 using the trace configuration file attached: $ sparc-rtems4.11-run both_hello.exe _Thread_Initialize (0x020013C0) 1] Objects_Information*(4) = 0203C70C 2] Thread_Control*(4) = 0203EB48 3] const Scheduler_Control*(4) = 02035FF8 4] void*(4) = 5] size_t(4) = 1000 6] bool(1) = 00 7] Priority_Control(4) = 00FF 8] bool(1) = 01 9] Thread_CPU_budget_algorithms(4) = 10] Thread_CPU_budget_algorithm_callout(4) = 11] uint32_t(4) = 12] Objects_Name(4) = 49444C45 _Thread_Initialize (0x020013C0) rt] bool(1) = 01 _Thread_Initialize (0x020013C0) 1] Objects_Information*(4) = 0203C5EC 2] Thread_Control*(4) = 0203F0F8 3] const Scheduler_Control*(4) = 02035FF8 4] void*(4) = 5] size_t(4) = 1000 6] bool(1) = 00 7] Priority_Control(4) = 0001 8] bool(1) = 00 9] Thread_CPU_budget_algorithms(4) = 10] Thread_CPU_budget_algorithm_callout(4) = 11] uint32_t(4) = 12] Objects_Name(4) = 55493120 _Thread_Initialize (0x020013C0) rt] bool(1) = 01 _Thread_Initialize (0x020013C0) 1] Objects_Information*(4) = 0203C86C 2] Thread_Control*(4) = 0203F940 3] const Scheduler_Control*(4) = 02035FF8 4] void*(4) = 5] size_t(4) = 2000 6] bool(1) = 01 7] Priority_Control(4) = 00FD 8] bool(1) = 01 9] Thread_CPU_budget_algorithms(4) = 10] Thread_CPU_budget_algorithm_callout(4) = 11] uint32_t(4) = 12] Objects_Name(4) = _Thread_Initialize (0x020013C0) rt] bool(1) = 01 Classic -- Hello World POSIX -- Hello World exit (0x02001324) 1] int(4) = I also attach the waf script I used to build the example. You need to build and install the rtl-host code to get a working rtems-tld. The 3 threads created are the Init, POSIX_Init and IDLE No code in RTEMS was altered to do this. Chris ; ; RTEMS Trace Linker Configuration: hello ; ; This script configure the both hello example to perform some ; tracing via the printf trace generator. ; [tracer] ; ; Name of the trace. ; name = Hello RTEMS Tracer ; ; Options can be defined here or on the command line. ; options = all-funcs, verbose ; ; Functions to trace. ; traces = hello-trace ; ; Define the function sets. These are the function's that can be ; added to the trace lists. ; functions = hello-trace ; ; Include RTEMS Trace support. ; include = rtems.ini, rtld-base.ini ; ; User application trace example. ; [hello-trace] generator = printk-generator signatures = hello-signatures trace = exit, Init, POSIX_Init, _Thread_Initialize header = #include rtems.h header = #include rtems/score/objectimpl.h header = #include rtems/score/scheduler.h [hello-signatures] exit=void, int Init = void, rtems_task_argument POSIX_Init = void*, void* _Thread_Initialize = bool, Objects_Information*, Thread_Control*, const Scheduler_Control*, void*, size_t, bool, Priority_Control, bool, Thread_CPU_budget_algorithms, Thread_CPU_budget_algorithm_callout, uint32_t, Objects_Name # Copyright 2013 Gedare Bloom (ged...@rtems.org) # Copyright 2014 Chris Johns (chr...@rtems.org) # # This file's license is 2-clause BSD as in this distribution's LICENSE.2 file. # # Waf build script for an RTEMS Hello import rtems_waf.rtems as rtems def build(bld): rtems.build(bld) if rtems.check_env(bld, 'RTEMS_TLD'): bld(features = 'c rtrace', target = 'both_hello.exe', source = ['test.c'], rtems_trace_cfg = '../../hello/both_hello/hello.ini') else: bld(features = 'c cprogram', target = 'both_hello.exe', source = ['test.c']) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS Linkers merged into The RTEMS Tools Project
Hello, I have merged the chrisj/rtl-host.git repo into The RTEMS Tools repo (rtems-tools.git) under the 'linkers' directory. Many thanks to all the people especially the GSoC students over the past few years who have contributed to this code base. Your efforts have been fantastic. The RTEMS linkers currently include the Run Time linker (rtems-ld) for creating images that can be dynamically loaded at runtime and the recently added Trace linker (rtems-tld). If you make use of the RTL host code please update to the RTEMS Tools repo as I will delete the rtl-host.git repo from my personal area sometime in the future. The merge allows the code to be refactored splitting into a library a number of C++ classes that provide a range of tools to access and manage ELF files and execute code on hosts as sub-processors. This code base will allow tools such as the Coverage Analysis tool (covoar) in the tester directory to make use of it. This years ESA Summer of Code in Space (SOCIS) project is already doing this so this change will allow us to merge that code in The RTEMS Tools project. In the future we would like to add libdwarf and get access to the ELF debug info. This will help us automatically and accurately generate function signatures used when tracing. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] shell: Add a ping command.
This patch adds a ping command to the RTEMS shell. It pings for a count of 5 or so and then stops because there is not ^C in the RTEMS shell. A flood ping also works with the -c option. As stated in the commit message some options work and some do not and I suspect the age of our TCP/IP stack is the reason. I have added doco to the patch but I have not built the doco because of the hassle on MacOS. This code needs to be changed to not use select and so avoid the issue of more than 64 fd's open. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] shell: Add a ping command.
The ping code is taken from a recent FreeBSD release. Some options have been tested, other not tested or do not work. This could be due to the age of our TCP/IP stack. This version of ping will not work if more than 64 file descriptors are open at once because the select FD size is 64 as set in newlib. --- cpukit/libmisc/Makefile.am |2 +- cpukit/libmisc/shell/main_ping.c | 1976 cpukit/libmisc/shell/shellconfig.h |7 + cpukit/libmisc/shell/sysexits.h| 116 +++ doc/shell/network.t| 311 +- 5 files changed, 2390 insertions(+), 22 deletions(-) create mode 100644 cpukit/libmisc/shell/main_ping.c create mode 100644 cpukit/libmisc/shell/sysexits.h diff --git a/cpukit/libmisc/Makefile.am b/cpukit/libmisc/Makefile.am index 421ddef..bcf8ff0 100644 --- a/cpukit/libmisc/Makefile.am +++ b/cpukit/libmisc/Makefile.am @@ -84,7 +84,7 @@ libshell_a_SOURCES = shell/cat_file.c shell/cmds.c shell/internal.h \ shell/main_mallocinfo.c shell/main_mdump.c shell/main_medit.c \ shell/main_mfill.c shell/main_mkdir.c shell/main_mount.c \ shell/main_mmove.c shell/main_msdosfmt.c \ -shell/main_mv.c shell/main_perioduse.c \ +shell/main_mv.c shell/main_perioduse.c shell/main_ping.c \ shell/main_pwd.c shell/main_rm.c shell/main_rmdir.c shell/main_sleep.c \ shell/main_stackuse.c shell/main_tty.c shell/main_umask.c \ shell/main_unmount.c shell/main_blksync.c shell/main_whoami.c \ diff --git a/cpukit/libmisc/shell/main_ping.c b/cpukit/libmisc/shell/main_ping.c new file mode 100644 index 000..a13d726 --- /dev/null +++ b/cpukit/libmisc/shell/main_ping.c @@ -0,0 +1,1976 @@ +#ifdef __rtems__ +#define __need_getopt_newlib +#include getopt.h +#endif +/* + * Copyright (c) 1989, 1993 + * The Regents of the University of California. All rights reserved. + * + * This code is derived from software contributed to Berkeley by + * Mike Muuss. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * 4. Neither the name of the University nor the names of its contributors + *may be used to endorse or promote products derived from this software + *without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#if !__rtems__ +#ifndef lint +static const char copyright[] = +@(#) Copyright (c) 1989, 1993\n\ + The Regents of the University of California. All rights reserved.\n; +#endif /* not lint */ + +#ifndef lint +static char sccsid[] = @(#)ping.c 8.1 (Berkeley) 6/5/93; +#endif /* not lint */ +#endif +#include sys/cdefs.h +__FBSDID($FreeBSD$); + +/* + * P I N G . C + * + * Using the Internet Control Message Protocol (ICMP) ECHO facility, + * measure round-trip-delays and packet loss across network paths. + * + * Author - + * Mike Muuss + * U. S. Army Ballistic Research Laboratory + * December, 1983 + * + * Status - + * Public Domain. Distribution Unlimited. + * Bugs - + * More statistics could always be gathered. + * This program has to run SUID to ROOT to access the ICMP socket. + */ + +#include sys/param.h /* NB: we rely on this for sys/types.h */ +#include sys/socket.h +#include sys/sysctl.h +#include sys/time.h +#include sys/uio.h + +#include netinet/in.h +#include netinet/in_systm.h +#include netinet/ip.h +#include netinet/ip_icmp.h +#include netinet/ip_var.h +#include arpa/inet.h + +#ifdef IPSEC +#include netipsec/ipsec.h +#endif /*IPSEC*/ + +#include ctype.h +//#include err.h +#include errno.h +#include math.h +#include netdb.h +#include signal.h +#include stdio.h +#include stdlib.h +#include string.h +//#include sysexits.h +#include unistd.h + +#include err.h +#include sysexits.h +#include sys/select.h + +#define
[PATCH] shell: Add an md5 hash command for files.
This command lets you get an MD5 hash for a file in an RTEMS file system.
---
cpukit/libmisc/Makefile.am | 6 +-
cpukit/libmisc/shell/main_md5.c| 110
cpukit/libmisc/shell/shellconfig.h | 6 ++
doc/shell/file.t | 206 +
4 files changed, 258 insertions(+), 70 deletions(-)
create mode 100644 cpukit/libmisc/shell/main_md5.c
diff --git a/cpukit/libmisc/Makefile.am b/cpukit/libmisc/Makefile.am
index 1091109..eaf1ffe 100644
--- a/cpukit/libmisc/Makefile.am
+++ b/cpukit/libmisc/Makefile.am
@@ -85,9 +85,9 @@ libshell_a_SOURCES = shell/cat_file.c shell/cmds.c
shell/internal.h \
shell/main_cp.c shell/main_cpuuse.c shell/main_date.c shell/main_dir.c \
shell/main_echo.c shell/main_exit.c shell/main_halt.c shell/main_help.c \
shell/main_id.c shell/main_logoff.c shell/main_ln.c shell/main_ls.c \
-shell/main_mallocinfo.c shell/main_mdump.c shell/main_medit.c \
-shell/main_mfill.c shell/main_mkdir.c shell/main_mount.c \
-shell/main_mmove.c shell/main_msdosfmt.c \
+shell/main_mallocinfo.c shell/main_md5.c shell/main_mdump.c \
+shell/main_medit.c shell/main_mfill.c shell/main_mkdir.c \
+shell/main_mount.c shell/main_mmove.c shell/main_msdosfmt.c \
shell/main_mv.c shell/main_perioduse.c shell/main_ping.c \
shell/main_pwd.c shell/main_rm.c shell/main_rmdir.c shell/main_sleep.c \
shell/main_stackuse.c shell/main_tty.c shell/main_umask.c \
diff --git a/cpukit/libmisc/shell/main_md5.c b/cpukit/libmisc/shell/main_md5.c
new file mode 100644
index 000..b0d1833
--- /dev/null
+++ b/cpukit/libmisc/shell/main_md5.c
@@ -0,0 +1,110 @@
+/*
+ * MD5 Shell Command Implmentation
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.com/license/LICENSE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include errno.h
+#include fcntl.h
+#include stdio.h
+#include stdlib.h
+#include sys/types.h
+#include unistd.h
+
+#include rtems.h
+#include rtems/shell.h
+
+#include md5.h
+
+#define BUFFER_SIZE (4 * 1024)
+
+static int rtems_shell_main_md5(
+ int argc,
+ char *argv[])
+{
+ uint8_t* buffer;
+ uint8_t hash[16];
+ size_t h;
+
+ buffer = malloc(BUFFER_SIZE);
+ if (!buffer)
+ {
+printf(error: no memory\n);
+return 1;
+ }
+
+ --argc;
+ ++argv;
+
+ while (argc)
+ {
+struct stat sb;
+MD5_CTX md5;
+int in;
+
+if (stat(*argv, sb) 0)
+{
+free(buffer);
+printf(error: stat of %s: %s\n, *argv, strerror(errno));
+return 1;
+}
+
+in = open(*argv, O_RDONLY);
+if (in 0)
+{
+free(buffer);
+printf(error: opening %s: %s\n, *argv, strerror(errno));
+return 1;
+}
+
+MD5Init(md5);
+
+while (sb.st_size)
+{
+ ssize_t size = sb.st_size BUFFER_SIZE ? BUFFER_SIZE : sb.st_size;
+
+ if (read(in, buffer, size) != size)
+ {
+close(in);
+free(buffer);
+printf(error: reading %s: %s\n, *argv, strerror(errno));
+return 1;
+ }
+
+ MD5Update(md5, buffer, size);
+
+ sb.st_size -= size;
+}
+
+MD5Final(hash, md5);
+
+close(in);
+
+printf(MD5 (%s) = , *argv);
+for (h = 0; h sizeof(hash); ++h)
+ printf(%02x, (int) hash[h]);
+printf(\n);
+
+--argc;
+++argv;
+ }
+
+ free(buffer);
+
+ return 0;
+}
+
+rtems_shell_cmd_t rtems_shell_MD5_Command = {
+ md5, /* name */
+ md5 [file ...], /* usage */
+ files, /* topic */
+ rtems_shell_main_md5, /* command */
+ NULL, /* alias */
+ NULL /* next */
+};
diff --git a/cpukit/libmisc/shell/shellconfig.h
b/cpukit/libmisc/shell/shellconfig.h
index 988bf88..eacfac2 100644
--- a/cpukit/libmisc/shell/shellconfig.h
+++ b/cpukit/libmisc/shell/shellconfig.h
@@ -71,6 +71,7 @@ extern rtems_shell_cmd_t rtems_shell_DD_Command;
extern rtems_shell_cmd_t rtems_shell_HEXDUMP_Command;
extern rtems_shell_cmd_t rtems_shell_DEBUGRFS_Command;
extern rtems_shell_cmd_t rtems_shell_DF_Command;
+extern rtems_shell_cmd_t rtems_shell_MD5_Command;
extern rtems_shell_cmd_t rtems_shell_RTC_Command;
@@ -382,6 +383,11 @@ extern rtems_shell_alias_t *rtems_shell_Initial_aliases[];
defined(CONFIGURE_SHELL_COMMAND_DF)
rtems_shell_DF_Command,
#endif
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+ !defined(CONFIGURE_SHELL_NO_COMMAND_MD5)) || \
+defined(CONFIGURE_SHELL_COMMAND_MD5)
+ rtems_shell_MD5_Command,
+#endif
/*
* RTEMS Related commands
diff --git a/doc/shell/file.t b/doc/shell/file.t
index eb38fe3..2db057d 100644
--- a/doc/shell/file.t
+++ b/doc/shell/file.t
@@ -36,6 +36,7 @@ The RTEMS shell has the following file and directory commands:
@item @code{mkrfs} - format RFS file system
@item @code{cd} - alias for chdir
@item @code{df} - display
ls broken in shell.
Hello, It looks like 'ls' is broken in the shell. On sparc/sis running fileio, selecting 's' for shell, logging in and then 'ls' exits the simulator. I saw this with mksh and assumed something was not working with mksh however this now looks like something in 'ls'. With mksh I traced the fault to the heap free call in mksh that failed on the heap check. I have not looked into the fileio failure. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] doc: Sort the shell file commands into alphabetical order.
---
doc/shell/file.t | 3039 --
1 file changed, 1559 insertions(+), 1480 deletions(-)
diff --git a/doc/shell/file.t b/doc/shell/file.t
index 2db057d..bda3d3d 100644
--- a/doc/shell/file.t
+++ b/doc/shell/file.t
@@ -11,32 +11,33 @@ The RTEMS shell has the following file and directory
commands:
@itemize @bullet
-@item @code{umask} - Set file mode creation mask
+@item @code{blksync} - sync the block driver
+@item @code{cat} - display file contents
+@item @code{cd} - alias for chdir
+@item @code{chdir} - change the current directory
+@item @code{chmod} - change permissions of a file
+@item @code{chroot} - change the root directory
@item @code{cp} - copy files
-@item @code{mv} - move files
-@item @code{pwd} - print work directory
+@item @code{dd} - format disks
+@item @code{debugrfs} - debug RFS file system
+@item @code{df} - display file system disk space usage
+@item @code{dir} - alias for ls
+@item @code{fdisk} - format disks
+@item @code{hexdump} - format disks
+@item @code{ln} - make links
@item @code{ls} - list files in the directory
-@item @code{chdir} - change the current directory
+@item @code{md5} - display file system disk space usage
@item @code{mkdir} - create a directory
-@item @code{rmdir} - remove empty directories
-@item @code{ln} - make links
+@item @code{mkdos} - DOSFS disk format
@item @code{mknod} - make device special file
-@item @code{chroot} - change the root directory
-@item @code{chmod} - change permissions of a file
-@item @code{cat} - display file contents
-@item @code{msdosfmt} - format disk
-@item @code{rm} - remove files
+@item @code{mkrfs} - format RFS file system
@item @code{mount} - mount disk
+@item @code{mv} - move files
+@item @code{pwd} - print work directory
+@item @code{rmdir} - remove empty directories
+@item @code{rm} - remove files
+@item @code{umask} - Set file mode creation mask
@item @code{unmount} - unmount disk
-@item @code{blksync} - sync the block driver
-@item @code{dd} - format disks
-@item @code{hexdump} - format disks
-@item @code{fdisk} - format disks
-@item @code{dir} - alias for ls
-@item @code{mkrfs} - format RFS file system
-@item @code{cd} - alias for chdir
-@item @code{df} - display file system disk space usage
-@item @code{md5} - display file system disk space usage
@end itemize
@@ -51,20 +52,19 @@ command as well as providing an example usage.
@c
@c
@page
-@subsection umask - set file mode creation mask
+@subsection blksync - sync the block driver
-@pgindex umask
+@pgindex blksync
@subheading SYNOPSYS:
@example
-umask [new_umask]
+blksync driver
@end example
@subheading DESCRIPTION:
-This command sets the user file creation mask to @code{new_umask}. The
-argument @code{new_umask} may be octal, hexadecimal, or decimal.
+This command XXX
@subheading EXIT STATUS:
@@ -72,156 +72,68 @@ This command returns 0 on success and non-zero if an error
is encountered.
@subheading NOTES:
-This command does not currently support symbolic mode masks.
+NONE
@subheading EXAMPLES:
-The following is an example of how to use @code{umask}:
+The following is an example of how to use @code{blksync}:
@example
-SHLL [/] $ umask
-022
-SHLL [/] $ umask 0666
-0666
-SHLL [/] $ umask
-0666
+EXAMPLE_TBD
@end example
@subheading CONFIGURATION:
-@findex CONFIGURE_SHELL_NO_COMMAND_UMASK
-@findex CONFIGURE_SHELL_COMMAND_UMASK
+@findex CONFIGURE_SHELL_NO_COMMAND_BLKSYNC
+@findex CONFIGURE_SHELL_COMMAND_BLKSYNC
This command is included in the default shell command set.
When building a custom command set, define
-@code{CONFIGURE_SHELL_COMMAND_UMASK} to have this
+@code{CONFIGURE_SHELL_COMMAND_BLKSYNC} to have this
command included.
This command can be excluded from the shell command set by
-defining @code{CONFIGURE_SHELL_NO_COMMAND_UMASK} when all
+defining @code{CONFIGURE_SHELL_NO_COMMAND_BLKSYNC} when all
shell commands have been configured.
@subheading PROGRAMMING INFORMATION:
-@findex rtems_shell_rtems_main_umask
+@findex rtems_shell_rtems_main_blksync
-The @code{umask} is implemented by a C language function
+The @code{blksync} is implemented by a C language function
which has the following prototype:
@example
-int rtems_shell_rtems_main_umask(
+int rtems_shell_rtems_main_blksync(
intargc,
char **argv
);
@end example
-The configuration structure for the @code{umask} has the
+The configuration structure for the @code{blksync} has the
following prototype:
@example
-extern rtems_shell_cmd_t rtems_shell_UMASK_Command;
+extern rtems_shell_cmd_t rtems_shell_BLKSYNC_Command;
@end example
@c
@c
@c
@page
-@subsection cp - copy files
+@subsection cat - display file contents
-@pgindex cp
+@pgindex cat
@subheading SYNOPSYS:
@example
-cp [-R [-H | -L | -P]] [-f | -i] [-pv] src target
-cp [-R [-H | -L] ] [-f | -i] [-NpPv] source_file ... target_directory
+cat file1 [file2 .. fileN]
@end example
@subheading DESCRIPTION:
-In the
Re: capture engine _States_Is_dormant check
On 17/09/2014 3:22 am, Jennifer Averett wrote: I am converting the capture engine to remove capture tasks and use a combination of a special capture record and data moved to the tcb to replace it. I have a question on the rtems_capture_switch_task method where it is using a check for dormant state of the current task. I spoke with Joel on this and neither of us can see how this condition can occur. Does anyone have any insight this.I think this chunk can go away, but don’t want to miss something. I cannot see a reason for this code any more. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
The JFFS2 file system can optionally use zlib as a compressor and if this is the only reference to zlib the application will not link. Adding -lz does not work because librtemscpu.a is added to the end of ld's command line via the bsp_specs hack and user added libraries appear before this. --- cpukit/wrapup/Makefile.am | 2 ++ cpukit/zlib/Makefile.am | 2 +- cpukit/zlib/preinstall.am | 14 -- 3 files changed, 3 insertions(+), 15 deletions(-) diff --git a/cpukit/wrapup/Makefile.am b/cpukit/wrapup/Makefile.am index e89426f..b8c0ee2 100644 --- a/cpukit/wrapup/Makefile.am +++ b/cpukit/wrapup/Makefile.am @@ -77,6 +77,8 @@ if NEWLIB TMP_LIBS += ../libmd/libmd.a endif +TMP_LIBS += ../zlib/libz.a + librtemscpu.a: $(TMP_LIBS) rm -f $@ $(MKDIR_P) $(ARCH) diff --git a/cpukit/zlib/Makefile.am b/cpukit/zlib/Makefile.am index 478134b..54be345 100644 --- a/cpukit/zlib/Makefile.am +++ b/cpukit/zlib/Makefile.am @@ -1,6 +1,6 @@ include $(top_srcdir)/automake/compile.am -project_lib_LIBRARIES = libz.a +noinst_LIBRARIES = libz.a libz_a_SOURCES = adler32.c libz_a_SOURCES += compress.c diff --git a/cpukit/zlib/preinstall.am b/cpukit/zlib/preinstall.am index 7eb8f7b..a17f25c 100644 --- a/cpukit/zlib/preinstall.am +++ b/cpukit/zlib/preinstall.am @@ -13,25 +13,11 @@ all-am: $(PREINSTALL_FILES) PREINSTALL_FILES = CLEANFILES += $(PREINSTALL_FILES) -all-local: $(TMPINSTALL_FILES) - -TMPINSTALL_FILES = -CLEANFILES += $(TMPINSTALL_FILES) - -$(PROJECT_LIB)/$(dirstamp): - @$(MKDIR_P) $(PROJECT_LIB) - @: $(PROJECT_LIB)/$(dirstamp) -PREINSTALL_DIRS += $(PROJECT_LIB)/$(dirstamp) - $(PROJECT_INCLUDE)/$(dirstamp): @$(MKDIR_P) $(PROJECT_INCLUDE) @: $(PROJECT_INCLUDE)/$(dirstamp) PREINSTALL_DIRS += $(PROJECT_INCLUDE)/$(dirstamp) -$(PROJECT_LIB)/libz.a: libz.a $(PROJECT_LIB)/$(dirstamp) - $(INSTALL_DATA) $ $(PROJECT_LIB)/libz.a -TMPINSTALL_FILES += $(PROJECT_LIB)/libz.a - $(PROJECT_INCLUDE)/zlib.h: zlib.h $(PROJECT_INCLUDE)/$(dirstamp) $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/zlib.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/zlib.h -- 1.8.5.2 (Apple Git-48) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] redirector: Rename rtems_stdio_redirect_t
On 17/09/2014 3:24 pm, Sebastian Huber wrote: Rename rtems_stdio_redirect_t to rtems_stdio_redirect since the namespace *_t is reserved by POSIX, see also The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, 2.2.2 The Name Space. Thanks. Please commit. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems capture: ctload and stack usage functionality
On 18/09/2014 3:30 am, Jennifer Averett wrote: Are there any objections to getting rid of the cpu usage and the stack checking capability in the capture engine. I think rtems cpu usage and rtems stack checker should be used instead. Keeping this information in the capture engine seems redundant and this minimizes information that has to be kept in the tcb when the capture task is removed. If there is actually any information that is not available by the other means, then we need to address that. I am trying to clean cruft out of the capture engine and simplify it. If there is a real need, we should find the best way to do it based on how things are implemented today. Removing the stack checker is fine. Monitoring the load can also go now the cpu usage has been fixed *but* the ctload command has a 'top' like display which is nice so 'cpuuse -t' or a 'top' command would be really really nice to have available. It would be a shame for this to go and the code be forgotten. :) Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: dynamic checking tools
On 18/09/2014 4:01 am, Daniel Gutson wrote: are there any dynamic checking tools (a la valgrind/helgrind/memcheck/drd and *sanitizer) for RTEMS? More specifically, I'm interested in memory and concurrency checking, more specifically for ARM. None that I know of. My limited understanding of these tools is their use of MMU features to work and the resultant effect on performance make it difficult to match up with RTEMS's runtime environment. RTEMS being a single process, single address space makes this sort of thing more complex and that is not taking into account the real-time issues due to the added overhead. In some RTEMS applications I have worked at the application level to allow the code or parts of the code to run on hosts that support the tools you list and then I run the code on that host. It requires planning and investment of time to make this happen but the pay off is well worth it. You only have to find a few issues to cover the costs. It is also nice to be able to run the code and see if any issues exist when chasing a problem on a target. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
On 18/09/2014 11:05 pm, Ralf Corsepius wrote: On 09/17/2014 02:26 AM, Chris Johns wrote: The JFFS2 file system can optionally use zlib as a compressor and if this is the only reference to zlib the application will not link. Moving libz.a into librtemscpu.a is not a wise idea. Why ? RTEMS is one source tree that must be built together and used as one so the idea of splitting libraries is counter to this. Yes years ago the separated libraries helped the link speed but those days are long gone. The zlib source not a separate package built separately and it can be argued the separation of this and other libraries without any specific versioning between them is bug and a big one. Adding -lz does not work because librtemscpu.a is added to the end of ld's command line via the bsp_specs hack and user added libraries appear before this. That's simply a bug somewhere. You should fix it. Yes using bsp_specs is simply a bug and a hack however it is too late to fix for 4.11 and RTEMS has dependences on these libraries so we need a solution. I looked into removing bsp_specs about 18months ago and saw no clear alternative without ripping out the build system and breaking all applications. That can happen after 4.11 has been released. There is a solution on the table that I am ok with for 4.11. It is not pretty or nice but it solves the current problem with little impact to users. If you have another solution in mind please provide a tested patch. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: bsp/tms570: actual state
On 19/09/2014 6:55 am, Pavel Pisa wrote: We need proper automated test suite setup - probably in Python and for sure with OpenOCD. Like this: http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtems-tester/rtems-tester.html ? Anyway, for real grade target project, they (in house), you, OAR, Embedded Brains or somebody else has to take care about the platform, its testing, certification, professional grade support etc. Daniel, I suggest you ask. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Moving to GCC 4.9
On 19/09/2014 9:17 pm, Joel Sherrill wrote: On September 19, 2014 12:00:26 AM CDT, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 18/09/14 23:47, Joel Sherrill wrote: Hi Is it possible to move all platforms to GCC 4.9.x? If not, which ones have issues and do these issues have GCC PRs filed? Thanks. The PowerPC build issues have been fixed. Also the C++ problem with GCC 4.9 for SMP configurations is fixed. So we should move to the latest GCC 4.9 release? We can discuss whether it makes sense to wait until my newlib inttypes.h work is done. Then we only make one tool bump. Newlib should be making monthly tarball snapshots starting in October per our request so that may be a good point to bump both. I will start the process of moving to 4.9. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: or1ksim: Updated results from RTEMS Tester
On 20/09/2014 12:56 am, Hesham Moustafa wrote: However, when I tested failures and timeouts separately, most of them work on QEMU, the others miss the trailing end-of-test line, which exists when I run them on or1ksim simulator. How many cores do you have and what host OS ? I assume this is not on a VM. The tester attempts to have a single test running on each core but the effect this can have may vary from host to host. The --jobs option is there to help. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: or1ksim: Updated results from RTEMS Tester
On 20/09/2014 3:13 pm, Hesham Moustafa wrote: I have 4 physical cores, and I usually run make with J8. My host OS is fedora 20. Try with --jobs=4 and see if you get any time outs. Anything else running at the same time may effect the result. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: or1ksim: Updated results from RTEMS Tester
On 21/09/2014 8:57 am, Hesham Moustafa wrote: On Sat, Sep 20, 2014 at 7:53 AM, Chris Johns chr...@rtems.org mailto:chr...@rtems.org wrote: On 20/09/2014 3:13 pm, Hesham Moustafa wrote: I have 4 physical cores, and I usually run make with J8. My host OS is fedora 20. Try with --jobs=4 and see if you get any time outs. Anything else running at the same time may effect the result. I did, but no big difference, the passed tests only raised to 446 although the system monitor was indicating an average processor throughput of 75% during this run instance with --job=4. What does --jobs=none return as results ? It also shows that I have 8 CPUs (2 virtual ones per one physical core). I am not sure what effect hyper-threading gives us in this case. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-tld update.
Hello, I have pushed updates to rtems-tld to rtems-tools.git plus changes to examples-v2 to trace into RTEMS. The trace for sparc/sis is attached. To run build and install the rtems-tools and install to the same location as my tools using the same prefix: $ git clone git://git.rtems.org/rtems-tools.git rtems-tools $ cd rtems-tools $ waf configure --prefix=$HOME/development/rtems/4.11 $ waf build install $ cd .. $ git clone git://git.rtems.org/examples-v2.git examples-v2 $ cd examples-v3 $ waf configure \ --rtems=$HOME/development/rtems/bsps/4.11 \ --rtems-tools=$HOME/development/rtems/4.11 $ waf Note, this assumes I have built and installed sparc/sis with a prefix of $HOME/development/rtems/bsps/4.11. Chris _Heap_Initialize (0x02003694) 1] Heap_Control*(4) = 0203FD7C 2] void*(4) = 02041150 3] uintptr_t(4) = 65E6 4] uintptr_t(4) = 0008 _Heap_Initialize (0x02003694) rt] uintptr_t(4) = 65D8 _Heap_Initialize (0x02003694) 1] Heap_Control*(4) = 0203F850 2] void*(4) = 02047736 3] uintptr_t(4) = 003B48CA 4] uintptr_t(4) = 0008 _Heap_Initialize (0x02003694) rt] uintptr_t(4) = 003B48C0 _Heap_Allocate_aligned_with_boundary (0x0200384C) 1] Heap_Control*(4) = 0203FD7C 2] uintptr_t(4) = 0018 3] uintptr_t(4) = 4] uintptr_t(4) = _Heap_Block_allocate (0x02003E78) 1] Heap_Control*(4) = 0203FD7C 2] Heap_Block*(4) = 02041150 3] uintptr_t(4) = 02041158 4] uintptr_t(4) = 0018 _Heap_Block_allocate (0x02003E78) rt] Heap_Block*(4) = 02041150 _Heap_Allocate_aligned_with_boundary (0x0200384C) rt] void*(4) = 02041158 _Heap_Allocate_aligned_with_boundary (0x0200384C) 1] Heap_Control*(4) = 0203FD7C 2] uintptr_t(4) = 1000 3] uintptr_t(4) = 4] uintptr_t(4) = _Heap_Block_allocate (0x02003E78) 1] Heap_Control*(4) = 0203FD7C 2] Heap_Block*(4) = 02041170 3] uintptr_t(4) = 02041178 4] uintptr_t(4) = 1000 _Heap_Block_allocate (0x02003E78) rt] Heap_Block*(4) = 02041170 _Heap_Allocate_aligned_with_boundary (0x0200384C) rt] void*(4) = 02041178 _Objects_Initialize_information (0x020013C0) 1] Objects_Information*(4) = 0203EE24 2] Objects_APIs(4) = 0001 3] uint16_t(2) = 0002 4] uint32_t(4) = 0002 5] uint16_t(2) = 004C 6] bool(1) = 00 7] uint32_t(4) = _Objects_Extend_information (0x020015E4) 1] Objects_Information*(4) = 0203EE24 _Heap_Allocate_aligned_with_boundary (0x0200384C) 1] Heap_Control*(4) = 0203FD7C 2] uintptr_t(4) = 0098 3] uintptr_t(4) = 4] uintptr_t(4) = _Heap_Block_allocate (0x02003E78) 1] Heap_Control*(4) = 0203FD7C 2] Heap_Block*(4) = 02042178 3] uintptr_t(4) = 02042180 4] uintptr_t(4) = 0098 _Heap_Block_allocate (0x02003E78) rt] Heap_Block*(4) = 02042178 _Heap_Allocate_aligned_with_boundary (0x0200384C) rt] void*(4) = 02042180 _Heap_Allocate_aligned_with_boundary (0x0200384C) 1] Heap_Control*(4) = 0203FD7C 2] uintptr_t(4) = 001C 3] uintptr_t(4) = 4] uintptr_t(4) = _Heap_Block_allocate (0x02003E78) 1] Heap_Control*(4) = 0203FD7C 2] Heap_Block*(4) = 02042218 3] uintptr_t(4) = 02042220 4] uintptr_t(4) = 001C _Heap_Block_allocate (0x02003E78) rt] Heap_Block*(4) = 02042218 _Heap_Allocate_aligned_with_boundary (0x0200384C) rt] void*(4) = 02042220 _Heap_Free (0x02003A04) 1] Heap_Control*(4) = 0203FD7C 2] void*(4) = _Heap_Free (0x02003A04) rt] bool(1) = 01 _Objects_Extend_information (0x020015E4) _Objects_Initialize_information (0x020013C0) _Objects_Allocate_unprotected (0x0200171C) 1] Objects_Information*(4) = 0203EE24 _Objects_Allocate_unprotected (0x0200171C) rt] Objects_Control*(4) = 02042180 _CORE_mutex_Initialize (0x02004030) 1] CORE_mutex_Control*(4) = 02042190 2] Thread_Control*(4) = 3] const CORE_mutex_Attributes*(4) = 023FFED0 4] bool(1) = 00 _CORE_mutex_Initialize (0x02004030) rt] CORE_mutex_Status(4) = _Objects_Allocate_unprotected (0x0200171C) 1] Objects_Information*(4) = 0203EE24 _Objects_Allocate_unprotected (0x0200171C) rt] Objects_Control*(4) = 020421CC _CORE_mutex_Initialize (0x02004030) 1] CORE_mutex_Control*(4) = 020421DC 2] Thread_Control*(4) = 3] const CORE_mutex_Attributes*(4) = 023FFED0 4] bool(1) = 00 _CORE_mutex_Initialize (0x02004030) rt] CORE_mutex_Status(4) = _Thread_Handler_initialization (0x020020E0) _Objects_Initialize_information (0x020013C0) 1] Objects_Information*(4) = 0203FE0C 2] Objects_APIs(4) = 0001 3] uint16_t(2) = 0001 4] uint32_t(4) = 0001 5] uint16_t(2) = 0588 6] bool(1) = 00 7] uint32_t(4) = 0008 _Objects_Extend_information (0x020015E4) 1] Objects_Information*(4) = 0203FE0C _Heap_Allocate_aligned_with_boundary (0x0200384C) 1] Heap_Control*(4) = 0203FD7C 2] uintptr_t(4) = 0588 3] uintptr_t(4) = 4] uintptr_t(4) = _Heap_Block_allocate (0x02003E78) 1]
Re: [PATCH 1/5] capture: Removal of capture task tracking.
On 23/09/2014 12:00 am, Jennifer Averett wrote:
This patch removes functionality for stack checking from
the capture engine and requiresi the use of existing rtems
functions for this information. It modifies ctload to use
functionality similar to rtems cpuusage. It removes the
capture task and stores a new capture task record the first
time the task is seen. The per task data that was still
needed is scaled down and stored in the tcb.
If the capture engine is not needed for ctload to work why not move that
code out of here and into the cpuuse command ? It would appear more
available to users.
---
cpukit/libmisc/capture/capture-cli.c| 383 ++--
cpukit/libmisc/capture/capture.c| 367 ++-
cpukit/libmisc/capture/capture.h| 295 --
cpukit/libmisc/capture/capture_user_extension.c | 219 +++---
cpukit/libmisc/capture/captureimpl.h| 53 +---
5 files changed, 420 insertions(+), 897 deletions(-)
diff --git a/cpukit/libmisc/capture/capture-cli.c
b/cpukit/libmisc/capture/capture-cli.c
index 2aa7c9c..6fe7e6c 100644
--- a/cpukit/libmisc/capture/capture-cli.c
+++ b/cpukit/libmisc/capture/capture-cli.c
@@ -35,12 +35,28 @@
#include rtems.h
#include rtems/capture-cli.h
#include rtems/monitor.h
-
+#include rtems/cpuuse.h
+#
#define RC_UNUSED __attribute__((unused))
#define RTEMS_CAPTURE_CLI_MAX_LOAD_TASKS (20)
/*
+ * Counter used to count the number of active tasks.
+ */
+static int rtems_capture_cli_task_count = 0;
+
+/*
+ * Array of tasks sorted by load.
+ */
+static rtems_tcb*
rtems_capture_cli_load_tasks[RTEMS_CAPTURE_CLI_MAX_LOAD_TASKS + 1];
+
+/*
+ * The load for each tcb at the moment rtems_capture_cli_load_tasks was
generated.
+ */
+static unsigned long long
rtems_capture_cli_load[RTEMS_CAPTURE_CLI_MAX_LOAD_TASKS + 1];
+
+/*
* The user capture timestamper.
*/
static rtems_capture_timestamp capture_timestamp;
@@ -233,6 +249,104 @@ rtems_capture_cli_print_timestamp (uint64_t uptime)
fprintf (stdout, %5lu:%02lu:%02lu.%09lu, hours, minutes, seconds,
nanosecs);
}
+static void
+rtems_capture_cli_print_task (rtems_tcb *tcb)
+{
+ rtems_task_priority ceiling = rtems_capture_watch_get_ceiling ();
+ rtems_task_priority floor = rtems_capture_watch_get_floor ();
+ rtems_task_priority priority;
+ int length;
+
+ priority = rtems_capture_task_real_priority (tcb);
+
+ fprintf (stdout, );
+ rtems_monitor_dump_id (rtems_capture_task_id (tcb));
+ fprintf (stdout, );
+ rtems_monitor_dump_name (rtems_capture_task_id (tcb));
+ fprintf (stdout, );
+ rtems_monitor_dump_priority (rtems_capture_task_start_priority (tcb));
+ fprintf (stdout, );
+ rtems_monitor_dump_priority (rtems_capture_task_real_priority (tcb));
+ fprintf (stdout, );
+ rtems_monitor_dump_priority (rtems_capture_task_curr_priority (tcb));
+ fprintf (stdout, );
+ length = rtems_monitor_dump_state (rtems_capture_task_state (tcb));
+ fprintf (stdout, %*c, 14 - length, ' ');
+ fprintf (stdout, %c%c,
+ 'a',
+ rtems_capture_task_flags (tcb) RTEMS_CAPTURE_TRACED ? 't' : '-');
+
+ if ((floor ceiling) (ceiling priority))
+fprintf (stdout, --);
+ else
+ {
+uint32_t flags = rtems_capture_task_control_flags (tcb);
+fprintf (stdout, %c%c,
+ rtems_capture_task_control (tcb) ?
+ (flags RTEMS_CAPTURE_WATCH ? 'w' : '+') : '-',
+ rtems_capture_watch_global_on () ? 'g' : '-');
+ }
+ fprintf (stdout, \n);
+}
+static void
+rtems_caputure_cli_print_record_std(rtems_capture_record_t* rec, uint64_t diff)
+{
+ uint32_t event;
+ int e;
+
+ event = rec-events RTEMS_CAPTURE_EVENT_START;
+
+ for (e = RTEMS_CAPTURE_EVENT_START; e RTEMS_CAPTURE_EVENT_END; e++)
+ {
+if (event 1)
+{
+ rtems_capture_cli_print_timestamp (rec-time);
+ fprintf (stdout, %9 PRId64 , diff);
+ rtems_monitor_dump_id (rec-task_id);
+ fprintf(stdout, %3 PRId32 %3 PRId32 %s\n,
+ (rec-events RTEMS_CAPTURE_REAL_PRIORITY_EVENT) 0xff,
+ (rec-events RTEMS_CAPTURE_CURR_PRIORITY_EVENT) 0xff,
+ rtems_capture_event_text (e));
+}
+event = 1;
+ }
+}
+
+static void
+rtems_caputre_cli_print_record_task(rtems_capture_record_t* rec)
+{
+ rtems_capture_task_record_t* task_rec = (rtems_capture_task_record_t*) rec;
+
+ rtems_capture_cli_print_timestamp (rec-time);
+ fprintf (stdout,);
+ rtems_monitor_dump_id (rec-task_id);
+ fprintf (stdout, %c%c%c%c,
+(char) (task_rec-name 24) 0xff,
+(char) (task_rec-name 16) 0xff,
+(char) (task_rec-name 8) 0xff,
+(char) (task_rec-name 0) 0xff);
+ fprintf (stdout, %3 PRId32%3 PRId32 \n,
+task_rec-start_priority,
+task_rec-stack_size);
+}
+
+/*
+ *
Re: [PATCH 1/5] capture: Removal of capture task tracking.
On 23/09/2014 10:29 pm, Jennifer Averett wrote: I tried to limit how much functionality I removed from the capture engine with this set of patches and limit it to what had to be removed in order to support removal of capture tasks. I have no problem with it moving to cpuuse, but I think it would need to be modified to use a printk plugin and account for __RTEMS_USE_TICKS_FOR_STATISTICS__ . This makes sense. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
On 24/09/2014 3:27 pm, Sebastian Huber wrote:
On 23/09/14 18:27, Gedare Bloom wrote:
On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
The code is m68k and the comment is PowerPC.
Sorry, a copy and paste error.
I did performance tests on both platforms with FTP transfers to/from
/dev/zero. I observed roughly 3% processor load in __divdi3() and
__moddi3() used by rtems_clock_get_uptime_timeval() and
rtems_clock_get_uptime_seconds().
Thanks.
Any guidance for the porting guide on what constitutes too expensive?
There
should be some general guidelines regarding when to pick a format
bases on
that.
I think if a target uses __divdi3(), then it is too costly. The focus
on 64-bit nanoseconds neglected that nearly all user API functions use
seconds.
Also.. This means that some ports will have 2038 issues at the score
level.
We have to address 64 bit time_t at some point.
Yes, we should move to 64-bit time_t after the next release or even now.
What is involved ?
It was proposed to use the bintime instead of 64-bit time_t (see [Bug
2180] New: _TOD_Get_with_nanoseconds() is broken on SMP)
The bintime is
struct bintime {
time_tsec;
uint64_t frac;
};
Most operations with timestamps use subtraction and comparison. On most
32-bit architectures this is efficient even for 64-bit values. The
problem is the division operation.
I am not sure understand what you are saying. Are you implying a
performance issue with bintime because it has a multiple to convert or
are you saying bintime ok to use ?
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
On 24/09/2014 3:42 pm, Sebastian Huber wrote: On 24/09/14 07:34, Chris Johns wrote: On 24/09/2014 3:27 pm, Sebastian Huber wrote: Yes, we should move to 64-bit time_t after the next release or even now. What is involved ? Something like this: diff --git a/newlib/libc/include/machine/types.h b/newlib/libc/include/machine/types.h index 40a75fa..b7265b9 100644 --- a/newlib/libc/include/machine/types.h +++ b/newlib/libc/include/machine/types.h @@ -11,7 +11,7 @@ #endif #define_CLOCK_T_ unsigned long /* clock() */ -#define_TIME_T_long/* time() */ +#define_TIME_T_long long /* time() */ #define _CLOCKID_T_unsigned long #define _TIMER_T_ unsigned long This is common to all newlib users. Did you mean to do that ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Separation of RTEMS sources and tool chain patches
On 30/09/2014 3:26 am, Peter Dufault wrote: On Sep 29, 2014, at 02:15 , Chris Johns chr...@rtems.org wrote: I can add the scripts to INI file format. I feel XML is too heavy a requirement for parsing. There is a single C++ file that does it and Python handles the format easily. I also think it is easier to read. Yes, INI is easier to read but XML is ubiquitous and easier to sell. I use tinyXML2. TinyXML2 has been complete enough for me, and the footprint is small enough for me even on my target devices. On the embedded PowerPC MPC5554: I am happy to have XML added to the report formats produced by the RSB. I still think INI is an easier format to handle and what we should embed in the RTEMS source tree. The data is not that complex. If this is an issue maybe INI and XML can be embedded. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Separation of RTEMS sources and tool chain patches
On 30/09/2014 6:28 pm, Sebastian Huber wrote: On 30/09/14 00:48, Chris Johns wrote: On 30/09/2014 3:26 am, Peter Dufault wrote: On Sep 29, 2014, at 02:15 , Chris Johns chr...@rtems.org wrote: I can add the scripts to INI file format. I feel XML is too heavy a requirement for parsing. There is a single C++ file that does it and Python handles the format easily. I also think it is easier to read. Yes, INI is easier to read but XML is ubiquitous and easier to sell. I use tinyXML2. TinyXML2 has been complete enough for me, and the footprint is small enough for me even on my target devices. On the embedded PowerPC MPC5554: I am happy to have XML added to the report formats produced by the RSB. I still think INI is an easier format to handle and what we should embed in the RTEMS source tree. The data is not that complex. If this is an issue maybe INI and XML can be embedded. The problem with INI is that it is a flat format. In XML you directly see the hierarchy (like in your plain text output, here you use indentation). There is no argument from me about which is a better overall format. With an XML library the parsing of XML files is easy. I have played with a number of XML parsers and found all sorts of issues in dark corners. I am happy to see it supported and I am also happy to see INI files supported. Is all the report stuff in source-builder/sb/reports.py? Yes. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-tester coverage patches break or1k/sis runs
On 2/10/2014 3:44 am, Joel Sherrill wrote:
Krzysztof/Hesham,
And devel@ since this needs to be public now.
I am trying to test or1ksim and sis using rtems-tester.
We need to get Krzysztof's patches merged and I am
just trying to run down all the issues I can.
You both have made some changes to the repository
and I am having issues. Krzysztof's are on a branch
for me and I have attached them. Except for the note
before the remains of the old email, all issues are
with Krzysztof's changes.
Hesham's are all committed.
$ ~/rtems-4.11-work/rtems-tools/tester/rtems-test --log=or1ksim.log
--rtems-bsp=sis --rtems-tools=/users/joel/rtems-4.11-work/tools
sparc-rtems4.11/c/sis/testsuites/samples/hello/
RTEMS Testing - Tester, v0.2.0
error: gdb.cfg:59: macro '%{_coverage}' not found
warning: switched to dry run due to errors
error: gdb.cfg:59: invalid if bool value: %if %{_coverage}
[1/1] p:0 f:0 t:0 i:0 | sparc/sis: hello.exe
There is something missing in the default configuration. The pattern
often used in this case is to define a default if the macro is not
defined before any logic that uses it.
When I use Krzysztof's branch with the or1ksim as shown below,
it adds a 1 to the end of the qemu-system-or32 invocation.
On 10/1/2014 11:19 AM, Hesham Moustafa wrote:
I cloned a vanilla RTEMS tester, and it works fine with me with the
following command
~/development/rtems/test/rtems-tester/tester/rtems-test
--log=or1ksim.log --rtems-bsp=or1ksim
/home/hesham/build/or1k-rtems4.11/c/or1ksim/testsuites/
But it seemed to run a long time and then I killed it when
I used your command.
And when I try to run it on sis, you do need the --rtems-tools
argument to find the simulator. I don't know what the difference
for this is when doing the or1ksim. I think it should be required
for consistency.
Yes, dependence on environment variables should not occur.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Problem to resolve sqrt symbol from shell/main_ping.c for lpc17xx_ea_ram BSP
On 2/10/2014 11:57 am, Pavel Pisa wrote:
Hello all,
when have tested recent master branch (fbe59f7c6756edc2952b13167893b85fe6e7aecb)
build configured for lpc17xx_ea_ram BSP, I am experiencing next error for my
code with networking enabled. It seems to be related to add of ping command.
Even addition of -lm to my LDFLAGS does not help
GCC call from OMK based makefile
arm-rtems4.11-gcc --pipe -B/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/ \
-specs bsp_specs -qrtems -march=armv7-m -mthumb \
-I
/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/include
\
-Wall -O2 -g init.o task_1.o \
-L/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/lib
\
-lbar -lnfs -lm -o
/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/bin/appnet
Error reported
/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/librtemscpu.a(libshell_a-main_ping.o):
In function `g_finish':
/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/rtems/arm-rtems4.11/c/lpc17xx_ea_ram/cpukit/libmisc/../../../../../../../../git/rtems/c/src/../../cpukit/libmisc/shell/main_ping.c:1642:
undefined reference to `sqrt'
collect2: error: ld returned 1 exit status
make[3]: ***
[/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/bin/appnet]
Error 1
make[2]: *** [binary-pass-this-dir] Error 2
make[1]: *** [binary-pass-appnet-subdir] Error 2
make: *** [binary-pass] Error 2
I have investigated how collect is called and even tried to modify it by adding
libm.a
/usr/arm-rtems4.11/gcc/4.9.1/bin/../libexec/gcc/arm-rtems4.11/4.9.1/collect2 \
-dc -dp -N -o
/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/bin/appnet
\
/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/start.o \
/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crti.o
\
/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crtbegin.o
\
-e _start \
-L/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/lib
\
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m
\
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/../../../../arm-rtems4.11/lib/thumb/armv7-m
\
-L/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1 \
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc \
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/../../../../arm-rtems4.11/lib
\
init.o task_1.o -lbar -lnfs \
/usr/arm-rtems4.11/lib/thumb/armv7-m/libm.a \
--start-group -lgcc --start-group -lrtemsbsp -lrtemscpu -lc -lgcc
--end-group \
-T /opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/linkcmds --end-group \
/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crtend.o
\
/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crtn.o
What seems to be problem cause is the fact, that bsp_specs adds libraries
group including librtemscpu.a after libm.a. Because libm.a is not in the group
then repeated search for sqrt() is not run after ping inclussion.
Adding libm at the end of manually crafted collect2 line helps
/usr/arm-rtems4.11/lib/thumb/armv7-m/libm.a
Sequence of link specification
%{qrtems: --start-group -lrtemsbsp -lrtemscpu -lc -lgcc --end-group %{!qn
is compiled in GCC driver /usr/arm-rtems4.11/gcc/4.9.1/bin/gcc, which is
defined in GCC sources
gcc-4.9.1/gcc/config/rtems.h
#undef LIB_SPEC
#define LIB_SPEC %{!qrtems: STD_LIB_SPEC } \
%{!nostdlib: %{qrtems: --start-group \
-lrtemsbsp -lrtemscpu \
-lc -lgcc --end-group %{!qnolinkcmds: -T linkcmds%s}}}
If float funtions support is needed by rtems core libraries then
-lm or libm.a has to be included in this define.
This is a great summary of the issue. We really cannot change this as it
stands until after 4.11 is released.
The problem is caused by ping statistic/standard deviation computation
in there
It is and it was a mistake on my part. My zynq testing has a NEON and
-lm was being linked so I was not aware of the issue.
cpukit/libmisc/shell/main_ping.c:1642
if (nreceived timing) {
double n = nreceived + nrepeats;
double avg = tsum / n;
double vari = tsumsq / n - avg * avg;
(void)printf(
round-trip min/avg/max/stddev = %.3f/%.3f/%.3f/%.3f ms\n,
tmin, avg, tmax, sqrt(vari));
}
I expect that problem can be hidden on hardware floating point
targets because sqrt is inlined/translated directly to FPU
instructions.
If the politics is not to require/pull in FPU support for core
libraries then I suggest to replace whole statistic computation
by fixed point/fraction based code or at least use integer/long based
sqrt replacement.
Or just remove the need
Re: [rtems commit] libmisc/shell: Remove the need for -lm when linking from the ping command.
On 4/10/2014 10:05 am, Gedare Bloom wrote:
On Fri, Oct 3, 2014 at 8:04 PM, Gedare Bloom ged...@rtems.org wrote:
On Fri, Oct 3, 2014 at 6:48 PM, Chris Johns chr...@rtems.org wrote:
Module:rtems
Branch:master
Commit:56ed56a641b69be42f5a38046307b33096014c84
Changeset:
http://git.rtems.org/rtems/commit/?id=56ed56a641b69be42f5a38046307b33096014c84
Author:Chris Johns chr...@rtems.org
Date: Sat Oct 4 08:55:12 2014 +1000
libmisc/shell: Remove the need for -lm when linking from the ping command.
Remove the use of sqrt and so the need to link to -lm.
Clean up some warnings.
static void
g_check_status(globals)
@@ -1638,10 +1639,16 @@ g_finish(globals)
if (nreceived timing) {
double n = nreceived + nrepeats;
double avg = tsum / n;
+#if defined(__rtems__)
+ (void) printf(
+ round-trip min/avg/max/stddev = %.3f/%.3f/%.3f ms\n,
Remove /stddev?
Actually, I'd suggest to just print the variance as it can be computed
relatively cheaply (compared to sqrt).
Ah yes I can change this. There is another step to remove the use of
floating point which Pavel raised and I think is a great idea. This is
just a simple clean up while that can be done.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] libcsupport: Add realpath.
---
cpukit/libcsupport/Makefile.am| 2 +-
cpukit/libcsupport/src/realpath.c | 253 ++
2 files changed, 254 insertions(+), 1 deletion(-)
create mode 100644 cpukit/libcsupport/src/realpath.c
diff --git a/cpukit/libcsupport/Makefile.am b/cpukit/libcsupport/Makefile.am
index d39f8f9..40e0800 100644
--- a/cpukit/libcsupport/Makefile.am
+++ b/cpukit/libcsupport/Makefile.am
@@ -119,7 +119,7 @@ TERMINAL_IDENTIFICATION_C_FILES += src/ttyname.c
LIBC_GLUE_C_FILES = src/__getpid.c src/__gettod.c src/__times.c \
src/truncate.c src/access.c src/stat.c src/lstat.c src/pathconf.c \
src/newlibc_reent.c src/newlibc_init.c src/newlibc_exit.c \
-src/kill_noposix.c src/utsname.c
+src/kill_noposix.c src/utsname.c src/realpath.c
BSD_LIBC_C_FILES = src/strlcpy.c src/strlcat.c src/issetugid.c
diff --git a/cpukit/libcsupport/src/realpath.c
b/cpukit/libcsupport/src/realpath.c
new file mode 100644
index 000..dff0838
--- /dev/null
+++ b/cpukit/libcsupport/src/realpath.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2003 Constantin S. Svintsoff kos...@iclub.nsu.ru
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the authors may not be used to endorse or promote
+ *products derived from this software without specific prior written
+ *permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#if defined(LIBC_SCCS) !defined(lint)
+static char sccsid[] = @(#)realpath.c 8.1 (Berkeley) 2/16/94;
+#endif /* LIBC_SCCS and not lint */
+#include sys/cdefs.h
+__FBSDID($FreeBSD: release/9.1.0/lib/libc/stdlib/realpath.c 240647 2012-09-18
13:03:00Z emaste $);
+
+#if !defined(__rtems__)
+#include namespace.h
+#endif
+#include sys/param.h
+#include sys/stat.h
+
+#include errno.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+#if !defined(__rtems__)
+#include un-namespace.h
+#endif
+
+/*
+ * Find the real name of path, by removing all ., .. and symlink
+ * components. Returns (resolved) on success, or (NULL) on failure,
+ * in which case the path which caused trouble is left in (resolved).
+ */
+char *
+realpath(const char * __restrict path, char * __restrict resolved)
+{
+ struct stat sb;
+ char *p, *q, *s;
+ size_t left_len, resolved_len;
+ unsigned symlinks;
+ int m, slen;
+ char left[PATH_MAX], next_token[PATH_MAX], symlink[PATH_MAX];
+
+ if (path == NULL) {
+ errno = EINVAL;
+ return (NULL);
+ }
+ if (path[0] == '\0') {
+ errno = ENOENT;
+ return (NULL);
+ }
+ if (resolved == NULL) {
+ resolved = malloc(PATH_MAX);
+ if (resolved == NULL)
+ return (NULL);
+ m = 1;
+ } else
+ m = 0;
+ symlinks = 0;
+ if (path[0] == '/') {
+ resolved[0] = '/';
+ resolved[1] = '\0';
+ if (path[1] == '\0')
+ return (resolved);
+ resolved_len = 1;
+ left_len = strlcpy(left, path + 1, sizeof(left));
+ } else {
+ if (getcwd(resolved, PATH_MAX) == NULL) {
+ if (m)
+ free(resolved);
+ else {
+ resolved[0] = '.';
+ resolved[1] = '\0';
+ }
+ return (NULL);
+ }
+ resolved_len = strlen(resolved);
+ left_len = strlcpy(left, path, sizeof(left));
+ }
+ if (left_len = sizeof(left) || resolved_len = PATH_MAX) {
+ if (m)
+ free(resolved);
+ errno = ENAMETOOLONG;
+
[PATCH 2/2] shell: Add an editor to the shell.
This is a small (21K on sparc) editor that provides some powerful features useful when a file needs editing on an embedded board. No need for copy off, edit, copy back --- cpukit/libmisc/Makefile.am |2 +- cpukit/libmisc/shell/main_edit.c | 2255 cpukit/libmisc/shell/shellconfig.h |6 + 3 files changed, 2262 insertions(+), 1 deletion(-) create mode 100644 cpukit/libmisc/shell/main_edit.c diff --git a/cpukit/libmisc/Makefile.am b/cpukit/libmisc/Makefile.am index 820a838..2f41ffa 100644 --- a/cpukit/libmisc/Makefile.am +++ b/cpukit/libmisc/Makefile.am @@ -109,7 +109,7 @@ libshell_a_SOURCES = shell/cat_file.c shell/cmds.c shell/internal.h \ shell/main_time.c shell/main_mknod.c \ shell/main_setenv.c shell/main_getenv.c shell/main_unsetenv.c \ shell/main_mkrfs.c shell/main_debugrfs.c shell/main_df.c \ -shell/main_lsof.c \ +shell/main_lsof.c shell/main_edit.c \ shell/main_blkstats.c \ shell/shell-wait-for-input.c diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c new file mode 100644 index 000..3097eeb --- /dev/null +++ b/cpukit/libmisc/shell/main_edit.c @@ -0,0 +1,2255 @@ +// +// edit.c +// +// Text editor +// +// Copyright (C) 2002 Michael Ringgaard. All rights reserved. +// +// Redistribution and use in source and binary forms, with or without +// modification, are permitted provided that the following conditions +// are met: +// +// 1. Redistributions of source code must retain the above copyright +//notice, this list of conditions and the following disclaimer. +// 2. Redistributions in binary form must reproduce the above copyright +//notice, this list of conditions and the following disclaimer in the +//documentation and/or other materials provided with the distribution. +// 3. Neither the name of the project nor the names of its contributors +//may be used to endorse or promote products derived from this software +//without specific prior written permission. +// +// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND +// ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +// IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +// ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE +// FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +// DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +// OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +// HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +// LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +// OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +// SUCH DAMAGE. +// + +#include signal.h +#include stdlib.h +#include stdio.h +#include stdarg.h +#include string.h +#include errno.h +#include fcntl.h +#include unistd.h +#include sys/stat.h + +#ifdef SANOS +#include os.h +#endif + +#ifdef __rtems__ +#include rtems.h +#include rtems/shell.h +#endif + +#if defined(__linux__) || defined(__rtems__) +#include sys/ioctl.h +#include termios.h +#define O_BINARY 0 +static int linux_console; +#endif + +#define MINEXTEND 32768 +#define LINEBUF_EXTRA 32 + +#ifndef TABSIZE +#define TABSIZE8 +#endif + +#ifndef INDENT +#define INDENT +#endif + +#define CLRSCR \033[0J\x1b[H\x1b[J +#define CLREOL \033[K +#define GOTOXY \033[%d;%dH +#define RESET_COLOR \033[0m + +#ifdef COLOR +#define TEXT_COLOR \033[44m\033[37m\033[1m +#define SELECT_COLOR \033[47m\033[37m\033[1m +#define STATUS_COLOR \033[0m\033[47m\033[30m +#else +#define TEXT_COLOR \033[0m +#define SELECT_COLOR \033[7m\033[1m +#define STATUS_COLOR \033[1m\033[7m +#endif + +// +// Key codes +// + +#define KEY_BACKSPACE0x101 +#define KEY_ESC 0x102 +#define KEY_INS 0x103 +#define KEY_DEL 0x104 +#define KEY_LEFT 0x105 +#define KEY_RIGHT0x106 +#define KEY_UP 0x107 +#define KEY_DOWN 0x108 +#define KEY_HOME 0x109 +#define KEY_END 0x10A +#define KEY_ENTER0x10B +#define KEY_TAB 0x10C +#define KEY_PGUP 0x10D +#define KEY_PGDN 0x10E + +#define KEY_CTRL_LEFT0x10F +#define KEY_CTRL_RIGHT 0x110 +#define KEY_CTRL_UP 0x111 +#define KEY_CTRL_DOWN0x112 +#define KEY_CTRL_HOME0x113 +#define KEY_CTRL_END 0x114 +#define KEY_CTRL_TAB 0x115 + +#define KEY_SHIFT_LEFT 0x116 +#define KEY_SHIFT_RIGHT 0x117 +#define KEY_SHIFT_UP 0x118 +#define KEY_SHIFT_DOWN 0x119 +#define KEY_SHIFT_PGUP 0x11A +#define KEY_SHIFT_PGDN 0x11B +#define KEY_SHIFT_HOME 0x11C +#define KEY_SHIFT_END0x11D +#define KEY_SHIFT_TAB0x11E +
GCC 4.9.1 changes.
Hi, There are a few issues with 4.9.1 which need to be looked at. I have not attempted a Windows build yet. My question is: Do we move the architectures that *do* build to 4.9.1 ? If there are patches or known option required to build the failing architectures please let me know. Is anyone test builind gcc head on a regular basis ? This is the list of architectures do not build: bfin: ../../../gcc-4.9.1/libgcc/fp-bit.c: In function '__divsf3': ../../../gcc-4.9.1/libgcc/fp-bit.c:1082:1: internal compiler error: in cfg_layout_initialize, at cfgrtl.c:4233 m32c: configure: error: unable to detect exception model mips: xgcc: error: addsf3: No such file or directory moxie: We are using binutils-2.24. Is there a later release ? CC_TLS -DUSE_EMUTLS -o _gcov.o -MT _gcov.o -MD -MP -MF _gcov.dep -DL_gcov -c ../../../../gcc-4.9.1/libgcc/libgcov-driver.c /tmp//cc7Lxv5S.s: Assembler messages: /tmp//cc7Lxv5S.s:176: Error: unknown opcode sex.b $r0,$r0 [ AG, a rather interesting name for an instruction ] powerpc: ../../../../gcc-4.9.1/libgcc/fp-bit.c: In function '_fpadd_parts': ../../../../gcc-4.9.1/libgcc/fp-bit.c:738:1: internal compiler error: in dwf_regno, at dwarf2cfi.c:909 Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RSB on Solaris 11.
On 6/10/2014 7:24 am, Karel Gardas wrote: Hello, I've been tempted to build latest/greatest RTEMS tool-chain on Solaris 11/i386 using RSB. The problem is that even sb-check fails in a way I'm not sure what to install or what's missing or in general wrong with the platform: $ ./source-builder/sb-check error: no hosts defaults found; please add Any idea how to debug this? BTW: This is both while using distro provided python 2.6 and also while using OpenCSW provided python 2.7 Please look in the directory source-builder/sb for linux.py, darwin.py and freebsd.py. Copy the closest to solaris.py and make the changes you need. Then edit options.py around line 517 and add solaris based on the Python os.uname() value. To test you can run 'python solaris.py' directly. Please send me any patches. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC 4.9.1 changes.
[ Add AG for the moxie issue ] On 9/10/2014 8:31 am, Joel Sherrill wrote: On 10/5/2014 1:23 AM, Chris Johns wrote: Hi, There are a few issues with 4.9.1 which need to be looked at. I have not attempted a Windows build yet. My question is: Do we move the architectures that *do* build to 4.9.1 ? I would lean to yes or wait for 4.9.2 to be released since it should be close. I will move the ones we know build. Newlib is now at the very latest via git. m32c: configure: error: unable to detect exception model Is this trying C++? No ... http://git.rtems.org/rtems-source-builder/tree/rtems/config/4.11/rtems-m32c.bset#n14 It is building libgcc which wants to know the exception model for some reason. I do not know if there is a configure option to handle this or something in our target support that is different. m32c does not support C++ at all. End of story. Understood. moxie: We are using binutils-2.24. Is there a later release ? CC_TLS -DUSE_EMUTLS -o _gcov.o -MT _gcov.o -MD -MP -MF _gcov.dep -DL_gcov -c ../../../../gcc-4.9.1/libgcc/libgcov-driver.c /tmp//cc7Lxv5S.s: Assembler messages: /tmp//cc7Lxv5S.s:176: Error: unknown opcode sex.b $r0,$r0 [ AG, a rather interesting name for an instruction ] Anthony, any ideas here ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Prototype for Init in confdefs.h
On 10/10/2014 9:17 pm, Sebastian Huber wrote:
Hello,
what was the reason for this change?
Maybe commit 2549b4d9a83d310e32329255a5a02604eb9e028b ?
commit d8b74dbebd341073f0c5b03e589d3fcd349745d1
Author: Chris Johns chr...@rtems.org
Date: Tue Apr 28 06:39:24 2009 +
2009-04-28 Chris Johns chr...@rtems.org
* sapi/include/confdefs.h: Add a prototype for Init with C
linkage
and define Init task command line arguments if confdefs.h
provides
an Init entry point.
diff --git a/cpukit/ChangeLog b/cpukit/ChangeLog
index 9432abc..477ce23 100644
--- a/cpukit/ChangeLog
+++ b/cpukit/ChangeLog
@@ -1,3 +1,9 @@
+2009-04-28 Chris Johns chr...@rtems.org
+
+ * sapi/include/confdefs.h: Add a prototype for Init with C linkage
+ and define Init task command line arguments if confdefs.h provides
+ an Init entry point.
+
2009-04-15 Ralf Corsepius ralf.corsep...@rtems.org
* configure.ac: Disable LIBSHELL for unix targets.
diff --git a/cpukit/sapi/include/confdefs.h
b/cpukit/sapi/include/confdefs.h
index 7f7a1ca..b50ff01 100644
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -518,7 +518,16 @@ rtems_fs_init_functions_trtems_fs_init_helper =
#endif
#ifndef CONFIGURE_INIT_TASK_ENTRY_POINT
+ #ifdef __cplusplus
+ extern C {
+ #endif
+rtems_task Init (rtems_task_argument );
+ #ifdef __cplusplus
+ }
+ #endif
#define CONFIGURE_INIT_TASK_ENTRY_POINT Init
+ extern const char* bsp_boot_cmdline;
+ #define CONFIGURE_INIT_TASK_ARGUMENTS ((rtems_task_argument)
bsp_boot_cmdline)
#endif
#ifndef CONFIGURE_INIT_TASK_INITIAL_MODES
This differs from the POSIX_Init treatment in the same file. For C++
this forces you to use a global Init function. In C you can also define
Init as static. This is a bit confusing.
Why not provide CONFIGURE_INIT_TASK_ENTRY_POINT and it can be whatever
linkage you like ?
I think the 'extern C' is not needed because there is another around
everything. I do not think nesting them makes the code more C than C. :)
At least Init and POSIX_Init should use similar definitions.
Sure.
I never use either constructs and use 'main'.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: warning in main_cp.c
On 13/10/2014 7:07 am, Joel Sherrill wrote: Hi I assume Chris knows the root cause of this. :) arm-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../altcycv_devkit/lib/include -I../../../../../../rtems/c/src/../../cpukit/libmisc/shell -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT shell/libshell_a-main_echo.o -MD -MP -MF shell/.deps/libshell_a-main_echo.Tpo -c -o shell/libshell_a-main_echo.o `test -f 'shell/main_echo.c' || echo '../../../../../../rtems/c/src/../../cpukit/libmisc/'`shell/main_echo.c ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/main_cp.c:108:1: warning: 'rtems_shell_cp_exit' defined but not used [-Wunused-function] It can be removed. There does not look like there is any calls to exit in the cp command. It is using errx. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Outstanding Qemu Patches
On 29/10/2014 9:31 am, Joel Sherrill wrote: I am back from the GSoC mentor summit and Chris will be home soon I guess. I tracked down the qemu project person who was there. Once again, he wasn't THE right person to address the patches we care about not getting in but he gave some hints. First I need a list of patches with descriptions. Hopefully I can push this and get the patches we care about upstreamed. Did you look in the RSB's configure for qemu ? It references some patches in qemu's patchworks. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Redundant Logging on User Extensions
On 30/10/2014 8:06 am, Joel Sherrill wrote: On 10/29/2014 4:01 PM, Gedare Bloom wrote: On Wed, Oct 29, 2014 at 2:42 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: Hi As Jennifer has reviewed the output from an SMP capture test, it is clear that something which was no big deal in the old fixed record uniprocessor version is now an issue. Most extensions have an actor and acted upon thread. For example, when a task is created, the calling task and new task are important. The actor and acted upon threads were logged in separate records. In an SMP system sorted by time, these two records can become disconnected. Since we now have variable length records, it makes sense to consolidate these into a single capture record. Any complaints? You probably want to support multiple ways to view the capture log, including sorting by core, or by some notion of system call e.g. the entire chain of events for a single thread creation. Agreed but in this case there are two records used to represent one logical event like task A created task B or task A restarted task B. We just want to combine two records into one in the log. This is fine. I suspect it will not be the last time something like this comes up. How it is sorted for display purposes is a user interface issue. Or how an import format supports it [1]. Jennifer, any interesting traces to tease us with ? Chris [1] http://www.efficios.com/ctf ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 Branching To Do
On 30/10/2014 10:49 am, Joel Sherrill wrote: + Run-Time Loader merged and tested A patch has been posted but it needs at least a v2 before being merged. I need to add tests and this needs a tool to generate a suitable kernel symbol table. I am working on adding this to the rtems-syms tool in the rtems-tools repo. That part is ok but it has uncovered an issue with the RTL code living in librtemscpu.a. It seems the symbol table's object file and the RTL in a library results in some strange dependency dance where unresolved externals happen. It is proving difficult to track down. I have faith you will resolve that before we get the other issues ironed out. Found it. The rtems-tools ELF frame work was adding local ELF symbols to the global symbol table. I have fixed it and now the testsuite test for libdl passes. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
libdl: rtems.git dependence on rtems-tools.git
Hi, Libdl tests in the testsuite depend on tools in rtems-tools.git/linkers. Should I raise a configure error if the tools are not found or not build the tests ? Raising an error is my preferred option because libdl for the supported archs is tested however it creates a dependency between rtems-tools.git and RTEMS. I can help with this by adding building of rtems-tools.git to the RSB's build of RTEMS tools. Comments ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libdl: rtems.git dependence on rtems-tools.git
On 31/10/2014 6:42 am, Gedare Bloom wrote: On Thu, Oct 30, 2014 at 3:40 PM, Gedare Bloom ged...@rtems.org wrote: On Thu, Oct 30, 2014 at 3:32 PM, Chris Johns chr...@rtems.org wrote: Hi, Libdl tests in the testsuite depend on tools in rtems-tools.git/linkers. Should I raise a configure error if the tools are not found or not build the tests ? Raising an error is my preferred option because libdl for the supported archs is tested however it creates a dependency between rtems-tools.git and RTEMS. I can help with this by adding building of rtems-tools.git to the RSB's build of RTEMS tools. Comments ? Only make it an error if building the rtems-tools/linker is part of the standard toolset builds, thus decreasing the burden on users who don't care to use libdl. Yes. Libdl only builds for the architectures there is relocation support for. The documentation on self-built tools, and whatever process we have for the authoritative tools guide should include notes regarding this. Sure. Do you have guide ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTL arm load failed
On 2/11/2014 8:28 pm, Peng Fan wrote: qemu-system-arm -no-reboot -net none -nographic -M realview-pbx-a9 -m 256M -kernel `find . -name dl01.exe` -s -S *** BEGIN OF TEST libdl (RTL) Loader 1 *** load: /dl-o1.o rtl: unsupported section: 15: type=1879048195 flags=00 handle: 0x212b10 has unresolved externals Thanks for the testing. dl-o1.o can not be correctly loaded, because of unresolved symbols. I do some debug using remote gdb and found it is the reloc entry references local symbols named LCx saying LC0, LC1, LC2. Freenix@linux-jyl1:~/per/new/build-arm arm-rtems4.11-readelf -s `find . -name dl-o1.o` Symbol table '.symtab' contains 22 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 FILELOCAL DEFAULT ABS dl-o1.c 2: 0 SECTION LOCAL DEFAULT1 3: 0 SECTION LOCAL DEFAULT3 4: 0 SECTION LOCAL DEFAULT4 5: 0 SECTION LOCAL DEFAULT5 6: 0 NOTYPE LOCAL DEFAULT5 $d * 7: 0 NOTYPE LOCAL DEFAULT5 .LC0* * 8: 0020 0 NOTYPE LOCAL DEFAULT5 .LC1* * 9: 0068 0 NOTYPE LOCAL DEFAULT5 .LC2* 10: 0 NOTYPE LOCAL DEFAULT1 $t 11: 0 SECTION LOCAL DEFAULT6 12: 0 SECTION LOCAL DEFAULT8 13: 0 SECTION LOCAL DEFAULT9 14: 0 SECTION LOCAL DEFAULT 11 15: 0 SECTION LOCAL DEFAULT 13 16: 0010 0 NOTYPE LOCAL DEFAULT 16 $d 17: 0 SECTION LOCAL DEFAULT 16 18: 0 SECTION LOCAL DEFAULT 14 19: 0 SECTION LOCAL DEFAULT 15 20: 000188 FUNCGLOBAL DEFAULT1 rtems_main 21: 0 NOTYPE GLOBAL DEFAULT UND printf The LCx symbols's type is NOTYPE and not included in the rtl symbol table(local symbol may should not be included). In rtl-elf.c, line 387 see following, the LCx symbols are not included, so fails. I prefer that if unresolved symbols detected in rtl, detailed info should be print out, but i found no debug msg about this. Unresolved symbols may not be an error. If you have 2 files dependent on each other one will be loaded with unresolved externals until the other is loaded. The loader handles this and when the second dependent module is loaded the unresolved symbols are resolved. This means the loader is not in a position to have a clear enough picture to decide if there are unresolved symbols. The application loading must decide when to check, check and raise an error when it thinks there should be no errors. 384 /* 385 * Only keep the functions and global or weak symbols. 386 */ 387 if ((ELF_ST_TYPE (symbol.st_info) == STT_OBJECT) || 388 (ELF_ST_TYPE (symbol.st_info) == STT_FUNC)) I think this cause arm load failed. Interesting. Nothing has changed here as ELF should always have these symbols. It must be this test does something our testing before did not highlight. I also suspect we will have issues with the RAP files. Let me explain. The code that was in my personal repo placed all global and local symbols into a single 'externals' symbol table. This worked because we had the awk hack to create the base image symbol table that used nm and nm only provided the global symbols. When I came to do the rtems-syms tool that takes a base kernel image and creates an exported symbols table I incorrectly ended up with the local symbols of the kernel in the symbol table and embedding that symbol table in the base image via the double link pass method failed on the second link. As a result I cleaned up the symbol code to have the rld::symbols classes load symbols into separate global, weak and local table. I suspect the RAP code is now only referencing the global table and so local symbols are not being included in the symbol table. I need to review this code. FYI, rap file are not included in the dl test? This is coming as I have time. It is needed. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: m32c libdl build error
On 4/11/2014 8:26 am, Joel Sherrill wrote: Hi Looks like a Makefile/configure issue. Seems so. There is no relocation code for m32c. There is for m32r. Chris gmake[6]: Entering directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-m32c-m32csim-rtems/m32c-rtems4.11/c/m32csim/cpukit/libdl' gmake[6]: *** No rule to make target `preinstall'. Stop. gmake[6]: Leaving directory `/users/joel/rtems-4.11-work/rtems-testing/rtems/build-m32c-m32csim-rtems/m32c-rtems4.11/c/m32csim/cpukit/libdl' gmake[5]: *** [preinstall-recursive] Error 1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: m32c libdl build error
On 4/11/2014 8:30 am, Joel Sherrill wrote: On 11/3/2014 3:29 PM, Chris Johns wrote: On 4/11/2014 8:26 am, Joel Sherrill wrote: Hi Looks like a Makefile/configure issue. Seems so. There is no relocation code for m32c. There is for m32r. Got a quick fix? This looks like the easiest of the failures so far. :( I checked the lists on cpukit/configure.ac and libtest/configure.ac and m32c is not listed and so LIBDL empties the Makefile. Does this mean a dummy preinstall target is needed ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: lm32 rtl-error.c causes gcc ICE
On 4/11/2014 8:25 am, Joel Sherrill wrote: Hi I suppose this needs to be narrowed down and fed into gcc's bugzilla. But I wanted to here from Chris first. lm32-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../lm32_evr/lib/include -DRTEMS_RTL_RAP_LOADER=1 -DRTEMS_RTL_ELF_LOADER=1 -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libdl_a-rtl-obj.o -MD -MP -MF .deps/libdl_a-rtl-obj.Tpo -c -o libdl_a-rtl-obj.o `test -f 'rtl-obj.c' || echo '../../../../../../rtems/c/src/../../cpukit/libdl/'`rtl-obj.c 0x70a8b5 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc-4.9.1/gcc/rtl-error.c:109 0x70a8e9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc-4.9.1/gcc/rtl-error.c:117 0x93096e insn_default_length(rtx_def*) /users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/lm32-rtems4.11-gcc-4.9.1-newlib-19-Aug-2014-1/build/gcc/insn-attrtab.c:143 Would it pay to check 4.9.2 and the latest newlib first ? Chris 0x595e8a shorten_branches(rtx_def*) ../../gcc-4.9.1/gcc/final.c:1191 0x5962ef rest_of_handle_shorten_branches ../../gcc-4.9.1/gcc/final.c:4519 0x5962ef execute ../../gcc-4.9.1/gcc/final.c:4548 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTL arm load failed
On 2/11/2014 8:28 pm, Peng Fan wrote: Hi, qemu-system-arm -no-reboot -net none -nographic -M realview-pbx-a9 -m 256M -kernel `find . -name dl01.exe` -s -S *** BEGIN OF TEST libdl (RTL) Loader 1 *** load: /dl-o1.o rtl: unsupported section: 15: type=1879048195 flags=00 handle: 0x212b10 has unresolved externals Fixed on head ... $ qemu-system-arm -no-reboot -net none -monitor none -serial stdio -nographic -M realview-pbx-a9 -m 256M -kernel `find . -name dl01.exe` *** BEGIN OF TEST libdl (RTL) Loader 1 *** load: /dl-o1.o handle: 0x2137d8 loaded Loaded module: argc:2 [../../../../../../../../rtems.master/c/src/../../testsuites/libtests/dl01/dl-o1.c] 0: Line 1 1: Line 2 Loaded module: argc:3 [../../../../../../../../rtems.master/c/src/../../testsuites/libtests/dl01/dl-o1.c] 0: Call 2, line 1 1: Call 2, line 2 2: Call 2, line 3 handle: 0x2137d8 closed *** END OF TEST libdl (RTL) Loader 1 *** Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/7] libdl/Makefile.am: Need preinstall on all targets
Hi Joel, These look fine. Chris On 5/11/2014 8:25 am, Joel Sherrill wrote: --- cpukit/libdl/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cpukit/libdl/Makefile.am b/cpukit/libdl/Makefile.am index 11f1478..5c3cd15 100644 --- a/cpukit/libdl/Makefile.am +++ b/cpukit/libdl/Makefile.am @@ -30,7 +30,7 @@ libdl_a_SOURCES = \ libdl_a_SOURCES += rtl-mdreloc-@RTEMS_CPU@.c libdl_a_CPPFLAGS = $(AM_CPPFLAGS) -DRTEMS_RTL_RAP_LOADER=1 -DRTEMS_RTL_ELF_LOADER=1 +endif + include $(srcdir)/preinstall.am include $(top_srcdir)/automake/local.am - -endif ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Test failures on arm/realview_pbx_a9_qemu
On 5/11/2014 6:14 pm, Sebastian Huber wrote: on the latest Git master the following new tests fail on arm/realview_pbx_a9_qemu due to a timeout after 180 seconds: top, dl01.pre and dl02.pre. The dl01.pre and dl02.pre are not to be run. They are the first link of two to get a suitable set of symbols. I will change the Makefile to not create exe files. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-tools commit] linkers: Disable .type statements in symbol code.
On 6/11/2014 12:15 pm, Joel Sherrill wrote: Which targets do you think this fixes? The i386 now builds. See my other email. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Is there plan for stable 4.10.3 release branching?
On 7/11/2014 4:05 am, Joel Sherrill wrote: Also Chris has RSB support for 4.10 tools so he should also comment to make sure he thinks it is ready. The 4.10 released binaries still exist and I have fixed all reported 4.10 issues. This will also be a good exercise for the new hosting. Yes this is a great idea. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-tools: Fix libpath failed for rtems-ld
On 8/11/2014 1:39 pm, Peng Fan wrote: we should not clear input parameter 'se' in rld::split, otherwise paths passed using '--lib-path' to rtems-ld will be cleared if standlibs are used. Thanks for this. I also have a patch for this in my repo. I will push it once git has been relocated and writes are enabled again. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: where to set newlib hash to bump git version
On 11/11/2014 3:59 am, Joel Sherrill wrote: Hi I would like to bump newlib to include my latest patches. The git tag is: commit ef252a3b72dffda2cc358a921c9c3487246852cc Where should this get changed in the RSB? http://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-gcc-4.9.2-newlib-git-1.cfg#n6 Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: gdb patches to RBS
On 15/11/2014 10:30 am, Jiri Gaisler wrote: On 11/14/2014 02:34 AM, Chris Johns wrote: On 14/11/2014 9:12 am, Jiri Gaisler wrote: What is the procedure to add gdb patches to RBS? Patches are first accepted by the RTEMS Project as the definition of the tools belongs to the project and tool packagers, ie the RSB, need to adopt that definition to get a project tick. Patches should be posted upstream where possible and then referenced from there. If the upstream does not have a suitable method to reference patches we can add them to the rtems-tools.git repo under the tools directory. There are specific cases such as the openrisc tools where a specific github instance is referenced as we have a positive undertaking from that community the tools are being merged upstream. Examples of upstream patch referencing is qemu and patchworks. I do not see a patch management system for gdb. There was talk back in April of this year of gdb using patchworks and then something else however it seems to have died out. I have a few patches that fixes the erc32 simulator and also add support for leon2 and leon3. This would allow us to drop the sis bsp, and also to test the leon2 and leon3 bsp's with sis. Excellent. I suggest you provide git patches for the rtems-tools.git repo to add the patches and then provide RSB patches for the sparc gdb build to use them. There are specific sparc patches already present which need updating as they are currently stopping us moving off gdb-7.7. I tried to move RBS to gdb-7.8.1, but there were several other dependency problems that I could not (easily) fix. Are these gdb, RSB, or rtems-tools patch issues ? So I have back-ported my patches to gdb-7.7 which seems to work equally well. I will send the patches for rtems-tools and rtems-source-builder to Chris off-list as the patch is quite large (300K). I built the sparc toolchain with RBS and copied the sis patch to rtems/patches manually since I have not write access to rtems-tools.git. Thanks for this. I have the patch and will push to rtems-tools once we can commit to the repos again. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Rehosting Update
On 20/11/2014 4:41 am, Hesham Moustafa wrote: + www.rtems.org http://www.rtems.org is alive there. (accept the certificate) + mailing lists never went down. They had been relocated months ago. This one is still down for me even after I accept the certificate. Make sure your caches are not getting the way. We are attempting to get a certificate sorted and we hope it will not take too long. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 4/4] libtests/malloctest/init.c: Fix warning
On 20/11/2014 6:59 am, Joel Sherrill wrote: + #pragma GCC diagnostic push + #pragma GCC diagnostic ignored -Wnonnull Do we allow the use of #pragma in RTEMS ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Coverity Issue with bdbuf.c
On 20/11/2014 2:10 pm, Joel Sherrill wrote: On November 19, 2014 8:37:47 PM CST, Gedare Bloom ged...@rtems.org wrote: I'm more concerned with the hard-coded cache alignment value, than I am with the dead code. The code is likely not doing what the surge intended but Chris needs to comment on that bases on git blame. :) Sebastian ? :) Definitely questionable having a hard coded value and then testing it. Yes it should be fixed for 4.11. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: upcoming set of capture engine patches
On 21/11/2014 8:04 am, Jennifer Averett wrote: The upcoming set of capture engine patches were submitted previously, requested changes made, and I tried to split the largest patch into 3 as suggested. They look fine to me. Love the trace at the end of the patch. Great work. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Update newlib to 20 Nov 2014 and hash de616601501c4f82968683e80c112604a2d40222
On 21/11/2014 9:03 am, Joel Sherrill wrote:
This picks up at least these RTEMS Project patches:
+ Joel Sherrill to ensure the PRIxxPTR defines are correct on all targets.
+ Sebastian Huber NGROUPS adjusted to have even value.
This is ok to push.
Chris
---
rtems/config/tools/rtems-gcc-4.9.2-newlib-git-1.cfg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rtems/config/tools/rtems-gcc-4.9.2-newlib-git-1.cfg
b/rtems/config/tools/rtems-gcc-4.9.2-newlib-git-1.cfg
index 67e5b35..051cae5 100644
--- a/rtems/config/tools/rtems-gcc-4.9.2-newlib-git-1.cfg
+++ b/rtems/config/tools/rtems-gcc-4.9.2-newlib-git-1.cfg
@@ -3,7 +3,7 @@
#
%define gcc_version4.9.2
-%define newlib_version 9b9f839addfe16ab0fd11f09a30a28139bfae6d5
+%define newlib_version de616601501c4f82968683e80c112604a2d40222
%hash md5 gcc-%{gcc_version}.tar.bz2 4df8ee253b7f3863ad0b86359cd39c43
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] 4.11/rtems-nios2.bset: Drop patch adding RTEMS target
On 22/11/2014 5:49 am, Joel Sherrill wrote: --- rtems/config/4.11/rtems-nios2.bset | 8 1 file changed, 8 deletions(-) Ok to push. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: moxie tools fails - dtc not available
On 22/11/2014 3:32 am, Joel Sherrill wrote: On 11/21/2014 10:17 AM, Joel Sherrill wrote: http://www.jdl.com/software/dtc-v1.2.0.tgz is no longer available and the download fails. The site appears to be dead. Any ideas where to fetch it from? http://www.devicetree.org/Device_Tree_Compiler points you to https://git.kernel.org/cgit/utils/dtc/dtc.git and they have bumped the version up to 1.4.1. Should the RSB be changed? Sure. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: mmap implementation was Re: [PATCH 2/4] sys/mman.h: New file. Clean up and add supporting stubs
On 22/11/2014 2:09 am, Joel Sherrill wrote: Chris has an implementation of some of the capabilities but I don't recall which git repo. I thought about merging that code but it doesn't have tests, documentation or confdefs.h support so just brought over the header and added stubs. The repo is http://git.rtems.org/chrisj/rtl.git/tree/. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] bsps/arm: Enable L2C for Cortex-A9 MPCore BSPs
On 21/11/2014 6:31 pm, Sebastian Huber wrote: On 21/11/14 06:10, Chris Johns wrote: On 21/11/2014 12:53 am, Sebastian Huber wrote: Module:rtems Branch:master Commit:50440c065e247899ee739d56cb1392c259289031 Changeset: http://git.rtems.org/rtems/commit/?id=50440c065e247899ee739d56cb1392c259289031 Author:Sebastian Huber sebastian.hu...@embedded-brains.de Date: Wed Nov 19 15:30:24 2014 +0100 bsps/arm: Enable L2C for Cortex-A9 MPCore BSPs --- +RTEMS_BSPOPTS_SET([BSP_DATA_CACHE_ENABLED],[*],[1]) +RTEMS_BSPOPTS_HELP([BSP_DATA_CACHE_ENABLED],[enable data cache]) + +RTEMS_BSPOPTS_SET([BSP_INSTRUCTION_CACHE_ENABLED],[*],[1]) +RTEMS_BSPOPTS_HELP([BSP_INSTRUCTION_CACHE_ENABLED],[enable instruction cache]) + To disable I provide configure with: BSP_DATA_CACHE_ENABLED=0 BSP_INSTRUCTION_CACHE_ENABLED=0 however this: +#if defined(BSP_DATA_CACHE_ENABLED) || defined(BSP_INSTRUCTION_CACHE_ENABLED) +/* Enable unified L2 cache */ +rtems_cache_enable_data(); +#endif and this: +#if !defined(RTEMS_SMP) \ + (defined(BSP_DATA_CACHE_ENABLED) \ +|| defined(BSP_INSTRUCTION_CACHE_ENABLED)) + /* Enable unified L2 cache */ + rtems_cache_enable_data(); +#endif only check for defined and it is always defined. These should check for the value only ie: #if BSP_DATA_CACHE_ENABLED || BSP_INSTRUCTION_CACHE_ENABLED ? You should use BSP_DATA_CACHE_ENABLED= BSP_INSTRUCTION_CACHE_ENABLED= for the configure. Urrr bletch sure if I have to. This is the first I have ever heard of doing this and it is confusing because the configure.ac code uses the value '1' and for me that implied a value of '0' had the opposite effect. I seem to remember other opts such as the reset one in the PC BSP taking 1 or 0. My preference these days is not to rely on 'defined()' tests. It avoids this type of error and the code reads much better. This is not the only case of BSPOPTS'less'ness we have in RTEMS but this one is an issue for me. Have I told you recently how much I dislike the BSPOPTS support. Yes, I know, but what is the alternative? These defines are already used for a lot of PowerPC BSPs and I don't think it is good to invent yet another solution for the same problem on ARM. I am not suggesting we change anything with this build system. I am suggesting we need to address this issue in 5.0 and a new build system and my concern is the mixed use of defined() and/or value testing in the code base. We need one consistent method and BSPOPTS has no structure and so the code has no formal approach and it is confusing to users because you need to check all references to see what it actually means. It is ok if you wrote the code but if you have not it is a slog to figure it all out. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: moxie tools fails - dtc not available
On 23/11/2014 3:00 am, Joel Sherrill wrote: On 11/21/2014 05:53 PM, Chris Johns wrote: On 22/11/2014 3:32 am, Joel Sherrill wrote: On 11/21/2014 10:17 AM, Joel Sherrill wrote: http://www.jdl.com/software/dtc-v1.2.0.tgz is no longer available and the download fails. The site appears to be dead. Any ideas where to fetch it from? http://www.devicetree.org/Device_Tree_Compiler points you to https://git.kernel.org/cgit/utils/dtc/dtc.git and they have bumped the version up to 1.4.1. Should the RSB be changed? Sure. OK. I am not wrapping my head around what needs to change. I know you are on travel but if you take a swing at a patch, I can test it. Please create a ticket. Thanks. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
