Removing Unused Material

The inclusion of functions and data from input relocatable object files, when this material is not used by the object being built, is wasteful. This unneeded material causes the object to be larger than necessary, resulting in added overhead when the object is used at runtime.

References to unused shared object dependencies are also wasteful. Particularly in the absence of lazy loading, these references result in the unnecessary loading and processing of these shared objects at runtime.

Unused sections, unused relocatable object files, and unused shared object dependencies can be diagnosed during a link-edit by using the link-editors debugging option -D unused.

Unused files and dependencies are also diagnosed when using the -z guidance option.

Unused sections, unused files, and unused dependencies should be removed from the link-edit. This removal reduces the cost of the link-edit, and reduces the runtime cost of using the object being built. However, if removing these items is problematic, unused material can be discarded from the object being built by using the -z discard-unused option.

Removing Unused Sections

An ELF section, from an input relocatable object file, is determined to be unused when three conditions are true.

• The section provides no global symbols.

• The section contributes to an allocatable segment.

• The section is not referenced by any other used section, from any object, that contributes to the link-edit.

Unused sections can be discarded from the link-edit by using the -z discard-unused=sections option.

You can improve the link-editor's ability to diagnose and discard unused sections by defining the dynamic object's external interfaces. See Chapter 9, Interfaces and Versioning. By defining an interface, global symbols that are not defined as part of the interface are reduced to locals. Reduced symbols that are unreferenced from other objects, are then clearly identified as candidates for discarding.

Individual functions and data variables can be discarded by the link-editor if these items are assigned to their own sections. This section refinement can be achieved by using the -xF compiler option.

Removing Unused Files

An input relocatable object file is determined to be unused if all allocatable sections provided by the relocatable object are unused.

Unused files are diagnosed with the -z guidance option, and can be discarded from the link-edit by using the -z discard-unused=files option.

The -z discard-unused option provides independent control over unused sections and unused files in order to compliment -z guidance processing. Under -z guidance, files that are determined to be unused are identified. Unused files can often easily be removed from a link-edit. However, sections that are determined to be unused are not identified under -z guidance processing. Unused sections can involve much more investigation and effort to remove and can be a consequence of compiler actions that are beyond your control.

By using the -z discard-unused=sections option together with the -z guidance option, unused sections are automatically removed, while unused files are identified for you to remove from the link-edit.

Removing Unused Dependencies

An explicit, shared object dependency is one that is defined on the command-line, either using the path name, or more commonly by using the -l option. Explicit dependencies include those that might be provided by the compiler drivers, such as -lc. An explicit dependency is determined to be unused if two conditions are true.

• No global symbols that are provided by the dependency are referenced from the object being built.

• The dependency does not compensate for the requirements of any implicit dependencies.

Unused dependencies are diagnosed with the -z guidance option, and can be discarded from the link-edit by using the -z discard-unused=dependencies option.

Implicit dependencies are the dependencies of explicit dependencies. Implicit dependencies can be processed as part of a link-edit to complete the closure of all symbol resolution. This symbol closure ensures that the object being built is self-contained, with no unreferenced symbols remaining.

All dynamic objects should define the dependencies they require. This requirement is enforced by default when building a dynamic executable, but is only enforced when building a shared object by using the -z defs option. In the unfortunate case where a shared object does not define the dependencies that the object requires, it can be necessary to supply an explicit dependency on the objects behalf. Such dependencies are referred to as compensating dependencies. The need for compensating dependencies can be eliminated by the systematic use of the -z defs option to build all dynamic objects.

Dynamic objects that do not define their dependencies should be correct. However, as these objects can require compensating dependencies to create a valid process, unused compensating dependencies are not removed by the -z discard-unused=dependencies option.

The -z ignore and -z record options are positional options that can be used in conjunction with the -z discard-unused=dependencies option. These positional options turn the discard feature on and off selectively for targeted objects.