Re: KICS! brainstorming
On 7/22/2014 1:05 PM, Daniel Gutson wrote: Hi, we are working in a very RAM constrained board, and noticed that some symbols could be moved to ROM by declaring them const. I have a slight idea about creating a consts-candidate detector tool KICS! (Keep It Const, St.! :) ), and wanted to hear some other people ideas. Initial thoughts: - one approach could be a gdb script, in which we first read all the RAM memory of global objects after initialization (#1), and compare the memory at the end (#2), see what remained unchanged; this could throw many false positives but would be a starting point. - another, I think tougher, is some pointer-tracking static analysis as a gcc plugin (not sure if it is even possible). Other ideas? A couple other idea without knowing the BSP. Turn on per function/data items sections. This has been done for the SPARC BSPs and had a pretty big impact on the size of the tests. I haven't heard any reports on real applications yet. This will require changing gcc and linking flags and tinkering with the linker script if it doesn't use * in all the right places for pattern matching. Put together a minimal version of your app. Basically just make the calls you know you need. Don't worry if it runs. Look through the symbol table and see if there are unexpected or undesired capabilities. For example, some BSPs unintentionally put the printk() support in the same file with the real console driver. Without per-function sections, something calls printk() and end up with the console driver and termios. If your application has lower requirements than what we think of as a minimum, we can refine our definition of minimum capabilities. All of these are important to us as a project. Knowing unexpected dependencies, turning on per item sections, and lowering minimum capabilities based on user feedbac. (#1) after bsp_start? after rtems_initialize_data_structures? (#2) for some user-definition of end, and/or after rtems_shutdown_executive or alike? Thanks! Daniel. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Tool Upstream Patch Update
Hi I have committed a few patches this week for multiple targets and wanted to pass along the news for those who care. + binutils-gdb: - or1k*-*-rtems* builds but requires a pending patch to disable gdb until OpenRISC folks submit their gdb port + newlib-cvs: - adjtime() prototype added. - settimeofday() and adjtime() now wrapped as BSD methods + gcc: - nios2*-*-rtems*: Support added to 4.9 branch and head. The backend nios2 support is finally upstream. :) - arm*-rtems*: Committed patch for Cortex-M4 and Cortex-R multilibs to 4.8, 4.9, and head There are pending patches moving through the OpenRISC project for or1k gcc support. They will be merged as part of the or1k target support being added. If anyone has any outstanding tool patches for these repositories that I missed, ping me. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: KICS! brainstorming
Thanks Joel, I will let you know once I address all your suggestions. Daniel. On Wed, Jul 23, 2014 at 10:28 AM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 7/22/2014 1:05 PM, Daniel Gutson wrote: Hi, we are working in a very RAM constrained board, and noticed that some symbols could be moved to ROM by declaring them const. I have a slight idea about creating a consts-candidate detector tool KICS! (Keep It Const, St.! :) ), and wanted to hear some other people ideas. Initial thoughts: - one approach could be a gdb script, in which we first read all the RAM memory of global objects after initialization (#1), and compare the memory at the end (#2), see what remained unchanged; this could throw many false positives but would be a starting point. - another, I think tougher, is some pointer-tracking static analysis as a gcc plugin (not sure if it is even possible). Other ideas? A couple other idea without knowing the BSP. Turn on per function/data items sections. This has been done for the SPARC BSPs and had a pretty big impact on the size of the tests. I haven't heard any reports on real applications yet. This will require changing gcc and linking flags and tinkering with the linker script if it doesn't use * in all the right places for pattern matching. Put together a minimal version of your app. Basically just make the calls you know you need. Don't worry if it runs. Look through the symbol table and see if there are unexpected or undesired capabilities. For example, some BSPs unintentionally put the printk() support in the same file with the real console driver. Without per-function sections, something calls printk() and end up with the console driver and termios. If your application has lower requirements than what we think of as a minimum, we can refine our definition of minimum capabilities. All of these are important to us as a project. Knowing unexpected dependencies, turning on per item sections, and lowering minimum capabilities based on user feedbac. (#1) after bsp_start? after rtems_initialize_data_structures? (#2) for some user-definition of end, and/or after rtems_shutdown_executive or alike? Thanks! Daniel. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
adjtime() changes
Hi I should point out that I am NOT trying to particularly improve the way we adjust time. I am only (1) making the code use timestamps not ticks (2) moving the adjust code to the SCORE The use of critical sections is exactly as it was before. The preferable way to adjust TOD is in small increments per clock tick. If someone is interested in great NTP support for RTEMS, please speak up. Volunteering or sponsoring some work would be of benefit to the community. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ 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
