6.3.2.2 Psect Information Listed By Module

The next section in the map file lists those modules that have made a contribution to the output and information regarding the psects that these modules have defined.

This section is heralded by the line that contains the headings:

Name   Link  Load  Length  Selector  Space  Scale

Under this on the far left is a list of object files (.o extension). Both object files that were generated from source modules and those extracted from object library files (.a extension) are shown. In the latter case, the name of the library file is printed before the object file list.

Next to the object file are the psects (under the Name column) that were linked into the program from that object file. Useful information about that psect is shown in the columns, as follows.

The linker deals with two kinds of addresses: link and load. Generally speaking, the Link address of a psect is the address by which it is accessed at runtime.

The Load address, which is often the same as the link address, is the address at which the psect starts within the output file (HEX or binary file etc.). If a psect is used to hold bits, the load address is irrelevant and is used to hold the link address (in bit units) converted into a byte address instead.

The Length of the psect is shown in the units that are used by that psect.

The Selector is less commonly used and is of no concern when compiling for PIC devices.

The Space field is important as it indicates the memory space in which the psect was placed. For Harvard architecture machines, with separate memory spaces (such as the PIC devices), this field must be used in conjunction with the address to specify an exact storage location. A space of 0 indicates the program memory and a space of 1 indicates the data memory (see 4.9.47.18 Space Flag).

The Scale of a psect indicates the number of address units per byte. This remains blank if the scale is 1 and shows 8 for psects that hold bit objects. The load address of psects that hold bits is used to display the link address converted into units of bytes, rather than the load address (see 4.9.47.2 Bit Flag).

For example, the following appears in a map file.

Name     Link  Load  Length Selector  Space  Scale
ext.o    text    3A    3A      22       30      0
         bss     4B    4B      10       4B      1
         rbit    50     A       2        0      1      8

This indicates that one of the files that the linker processed was called ext.o.

This object file contained a text psect, as well as psects called bss and rbit.

The psect text was linked at address 3A and bss at address 4B. At first glance, this seems to be a problem, given that text is 22 words long. However, they are in different memory areas, as indicated by the space flag (0 for text and 1 for bss), and so they do not even occupy the same memory space.

The psect rbit contains bit objects, and this can be confirmed by looking at the scale value, which is 8. Again, at first glance it seems that there could be an issue with rbit linked over the top of bss. Their space flags are the same, but since rbit contains bit objects, its link address is in units of bits. The load address field of rbit psect displays the link address converted to byte units, i.e., 50h/8 => Ah.