= Add Per Function and Data Element Section Support to a BSP = [[TOC(GCI/Coding/AddPerSectionSupportToBSPs, depth=2)]] When a program is compiled and linked, the linker attempts to resolve all references to functions and data elements required by the program. By default, the GNU linker will place an entire object file into an application executable even if only one symbol is required by the application. This can lead to unused code in an executable. This is undesirable from both an application image size and code review perspective. The GNU tools, specifically GCC and GNU ld, have support for a special compilation and linking mode which results in only the referenced symbols being placed into an application executable. However, there are known cases where the application and supporting software are not 100% correct and all needed functions and data are not referenced in a way that results in GNU ld pulling in all needed methods and data. Although large parts of RTEMS are carefully implemented to have only one method per file, experiments with turning on this capability have shown reductions in RTEMS test programs and user applications of up to 50% in overall size. This task consists of turning on this capability for a specific BSP family. A BSP family is the collection of BSPs under a single directory such as c/src/lib/libbsp/CPU/BSP_FAMILY. The make/custom directory has a BSP.cfg file for each BSP which may be built. If the BSP Family supports multiple BSP variants, the BSP.cfg files may include either a shared ".inc" file or a base ".cfg" file with common settings. All BSPS for the SPARC architecture support this advanced capability. For an example, see the file c/src/lib/libbsp/sparc/erc32/make/custom/erc32.cfg. Note the following lines at the bottom of the file which turn on the advanced capabilities. {{{ # Add CFLAGS and LDFLAGS for compiling and linking with per item sections CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections LDFLAGS = -Wl,--gc-sections }}} This is also a BSP Family with multiple BSP variants. The sis.cfg file includes erc32.cfg so editing one file impacts both BSPs. == Task Requirements == In the description of this task, you were given a BSP Family to enable this capability for. The BSP Family will be named CPU/BSP_FAMILY which indicates its location in the source tree and implies a set of BSP variants as described above. The task requires you to: Build a toolset for the CPU architecture per the instruction in the Hello World task. You likely did this for sparc/sis. In that case, sparc was the eCPU and sis was the BSP. Be prepared to generate a proper patch for your changes. Build each BSP in the BSP family with the configure option "--enable-tests=samples" Record the size of the sample executables as reported by the size command for this architecture. The build output has this information but it can be obtained by running a command similar to the following from the top of the build directory: {{{ find . -name "*.exe" | while read f; do (cd `dirname $f `; mips-rtems4.12-size `basename $f`); done | grep "\.exe" }}} Note that CPU will have to be replaced with the appropriate CPU architecture. Edit one or more .cfg and .inc files to add the appropriate options to CFLAGS_OPTIMIZE_V and LDFLAGS as shown in the previous section. Rebuild the BSP variants in the BSP Family and again note the size. If there is no reduction, something is not right. If the reduction is near 100%, then something is not right. If the BSP variant is one which can be tested on a simulator, then you need to test it. The commit message for your patch should be similar to the following one which was used for the mips/jmr3904 BSP. {{{ mips/jmr3904: Add per-section compilation and linking support The size of the sample executables without this option were: 128028 1812 12224 142064 22af0 ticker.exe 52600 1324 8192 62116 f2a4 minimum.exe 1156240 2168 19696 1178104 11f9f8 cxx_iostream.exe 706952 5908 24600 737460 b40b4 fileio.exe 243232 2372 14084 259688 3f668 capture.exe 155660 1940 12376 169976 297f8 nsecs.exe 201256 2212 12896 216364 34d2c paranoia.exe 253696 1872 12576 268144 41770 cdtest.exe 124452 1812 12208 138472 21ce8 base_sp.exe 127640 1844 15648 145132 236ec unlimited.exe 133452 1780 11760 146992 23e30 hello.exe The size of the sample executables with this option enabled were: 115052 1712 12096 128860 1f75c ticker.exe 40760 1256 8144 50160 c3f0 minimum.exe 671768 2076 18688 692532 a9134 cxx_iostream.exe 679672 5696 23992 709360 ad2f0 fileio.exe 227384 2196 13924 243504 3b730 capture.exe 143132 1832 12248 157212 2661c nsecs.exe 187736 2104 12768 202608 31770 paranoia.exe 234324 1788 12448 248560 3caf0 cdtest.exe 111556 1712 12080 125348 1e9a4 base_sp.exe 112876 1744 15520 130140 1fc5c unlimited.exe 118120 1688 11696 131504 201b0 hello.exe }}} If you noticed that cxx_iostream.exe dropped in size the most, this is because it is a C++ application while the others were C applications. Actual savings will vary by BSP.