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