Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
8.  Mapfile Option Mapping Example  Previous   Contents   Next 
   
 

Mapfile Option Defaults

The link-editor defines four built-in segments (text, data, bss and note) with default segment_attribute_values and corresponding default mapping directives. Even though the link-editor does not use an actual mapfile to provide the defaults, the model of a default mapfile helps illustrate what happens when the link-editor encounters your mapfile.

The following example shows how a mapfile would appear for the link-editor defaults. The link-editor begins execution behaving as if the mapfile has already been read in. Then the link-editor reads your mapfile and either augments or makes changes to the defaults.

        text = LOAD ?RX; 
        text : ?A!W; 
        data = LOAD ?RWX; 
        data : ?AW; 
        note = NOTE; 
        note : $NOTE;

As each segment declaration in your mapfile is read in, it is compared to the existing list of segment declarations as follows:

  1. If the segment does not already exist in the mapfile but another with the same segment-type value exists, the segment is added before all of the existing segments of the same segment_type.

  2. If none of the segments in the existing mapfile has the same segment_type value as the segment just read in, then the segment is added by segment_type value to maintain the following order:

    INTERP

    LOAD

    DYNAMIC

    NOTE

  3. If the segment is of segment_type LOAD and you have defined a virtual_address value for this LOADable segment, the segment is placed before any LOADable segments without a defined virtual_address value or with a higher virtual_address value, but after any segments with a virtual_address value that is lower.

As each mapping directive in a mapfile is read in, the directive is added after any other mapping directives that you already specified for the same segment but before the default mapping directives for that segment.

Internal Map Structure

One of the most important data structures in the ELF-based link-editor is the map structure. A default map structure, corresponding to the model default mapfile, is used by the link-editor. Any user mapfile will augment or override certain values in the default map structure.

A typical although somewhat simplified map structure is illustrated in Figure 8-1. The "Entrance Criteria" boxes correspond to the information in the default mapping directives. The "Segment Attribute Descriptors" boxes correspond to the information in the default segment declarations. The "Output Section Descriptors" boxes give the detailed attributes of the sections that fall under each segment. The sections themselves are shown in circles.

Figure 8-1 Simple Map Structure

The link-editor performs the following steps when mapping sections to segments:

  1. When a section is read in, the link-editor checks the list of Entrance Criteria looking for a match. All specified criteria must be matched.

    In Figure 8-1, a section that falls into the text segment must have a section_type value of $PROGBITS and have a section_flags value of ?A!W. It need not have the name .text since no name is specified in the Entrance Criteria. The section can be either X or !X in the section_flags value because nothing was specified for the execute bit in the Entrance Criteria.

    If no Entrance Criteria match is found, the section is placed at the end of the output file after all other segments. No program header entry is created for this information.

  2. When the section falls into a segment, the link-editor checks the list of existing Output Section Descriptors in that segment as follows:

    If the section attribute values match those of an existing Output Section Descriptor exactly, the section is placed at the end of the list of sections associated with that Output Section Descriptor.

    For instance, a section with a section_name value of .data1, a section_type value of $PROGBITS, and a section_flags value of ?AWX falls into the second Entrance Criteria box in Figure 8-1, placing it in the data segment. The section matches the second Output Section Descriptor box exactly (.data1, $PROGBITS, ?AWX) and is added to the end of the list associated with that box. The .data1 sections from fido.o, rover.o, and sam.o illustrate this point.

    If no matching Output Section Descriptor is found but other Output Section Descriptors of the same section_type exist, a new Output Section Descriptor is created with the same attribute values as the section and that section is associated with the new Output Section Descriptor. The Output Section Descriptor and the section are placed after the last Output Section Descriptor of the same section type. The .data2 section in Figure 8-1 was placed in this manner.

    If no other Output Section Descriptors of the indicated section type exist, a new Output Section Descriptor is created and the section is placed in that section.

    Note - If the input section has a user-defined section type value between SHT_LOUSER and SHT_HIUSER, it is treated as a $PROGBITS section. No method exists for naming this section_type value in the mapfile, but these sections can be redirected using the other attribute value specifications (section_flags, section_name) in the entrance criteria.

  3. If a segment contains no sections after all of the command line object files and libraries are read in, no program header entry is produced for that segment.

Note - Input sections of type $SYMTAB, $STRTAB, $REL, and $RELA are used internally by the link-editor. Directives that refer to these section types can only map output sections produced by the link-editor to segments.

 		 
 
  Previous   Contents   Next