Add Per Function and Data Element Section Support to a BSP

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" | xargs -e CPU-rtems4.12-size

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:

CPU/BSP_FAMILY: Add per-section compilation and linking support

The size of the sample executables without this option were:

FILL ME IN WITH BEFORE INFORMATION

The size of the sample executables with this option enabled were:

FILL ME IN WITH AFTER INFORMATION