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.