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 <[email protected]> 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 > [email protected] On-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 [email protected] http://lists.rtems.org/mailman/listinfo/devel
