280 Chapter 9. Linker/Locator

NOTE

Typically, the Lx51 linker/locator generates overlay information that is accurate. However, in some instances the default analysis of the call tree is ineffective or incorrect. This occurs with indirectly called functions through function pointers and functions that are called by both the main program and an interrupt function.

Program and Data Segments of Functions

?PR?, ?BI?, ?DT?, ?XD?, ?ID?, ?PD?, ?ED?, ?EB?, and ?HD? is derived from the memory class. In addition each bit and data segment must have the relocation type OVERLAYABLE.

The Cx51 compiler and PL/M-51 compiler define automatically local data segments according to these rules. However, if you use overlayable segments in your assembly modules, you must follow these naming conventions. Refer to “SEGMENT” on page 106 for information on how to declare segments.

Example for Segment declaration in assembly language:

?PR?func1?module1 SEGMENT CODE ; segment for func1 code ?DT?func1?module1 SEGMENT DATA OVERLAYABLE ; data segment belongs to func1

More information can be found in the Keil Application Note 149: Data Overlaying and Code Banking with Assembler Modules that is available on www.keil.com or the Keil development tools CD-ROM.

282 Chapter 9. Linker/Locator

Disable Data Overlaying

at Cx51 compiler level or with the OVERLAY control at the Lx51 linker/locator command line as follows:

You can invoke the Lx51 linker/locator with the NOOVERLAY option to disable data overlaying for the entire application.

The Lx51 linker/locator control OVERLAY (sfname ! *) disables data overlaying for the function specified by sfname.

C code that is translated with the Cx51 compiler directive OPTIMIZE (1) does not use the relocation type OVERLAYABLE. Therefore the local data segments of this code portions cannot be overlaid.

284 Chapter 9. Linker/Locator

is passed in the function main. Since main contains the reference, the Lx51 linker/locator thinks that main calls indirectfunc1 and indirectfunc2. But this is incorrect, since the real function call is in the function execute.

Following is a program listing for this example.

:

:

bit indirectfunc1 (void) { /* indirect function 1 */ unsigned char n1, n2;

return (n1 < n2);

execute (indirectfunc1); else

execute (indirectfunc2);

}

:

:

The following listing file shows the overlay map for the program before making adjustments with the OVERLAY control.

The entry for ?PR?MAIN?OVL1 shows a call to ?PR?INDIRECTFUNC1?OVL1,

?PR?EXECUTE?OVL1, and ?PR?INDIRECTFUNC2?OVL1. However, only the

function execute is called from main. The other references are results from using the function pointer fct, which is passed to execute. The function call to

indirectfunc1 and indirectfunc2 takes place in execute, not in main where

the functions are referenced.

In this situation, the linker/locator cannot locate the actual function calls. Therefore, the Lx51 linker/locator incorrectly overlays the local segments of the functions execute, indirectfunc1, and indirectfunc2. This might result in a data overwrites of the variables i and fct.

You can use the OVERLAY control to correct the function call tree as it seen by the linker. For this example, you must remove the references from main to

indirectfunc1 and indirectfunc2. Do this with main ~ (indirectfunc1,

indirectfunc2). Then, add the actual function call from execute to

indirectfunc1 and indirectfunc2 with executed ! (indirectfunc1,

indirectfunc2). The following shows the complete linker invocation line for this example.

execute ! (indirectfunc1, indirectfunc2))

With this Lx51 invocation the overlay map shows the correct references.

Pointer to a Function in Arrays or Tables

Another typical scenario is an array that contains a pointer to a function. This is typical for applications with function tables. In the following example, func1 and func2 are called indirectly by main but the entry points are stored as constant values in the table functab. This table is located in the segment ?CO?modulname. Therefore, the ?CO?OVL2 segment contains references to func1

and func2.

In reality, however, the calls are executed from the main function. But, the Lx51 linker/locator assumes that func1 and func2 are recursive called, because in func1 and func2 constant strings are used. These constants strings are also stored in the segment ?CO?OVL2. The result is that the Lx51 linker/locator reports warnings which indicate recursive calls from the segment

func1 and func2.

The following listing shows part of the OVL2 program.

(*functab [P1 & 0x01]) ();

}

.

.

.

The Lx51 linker/locater generates typically warnings when you generate programs that contain a table with pointer to functions. Although the program can be executed correct in this example above, the references should be adjusted to the real calls. In the real application the functions func1 and func2 are called by the main function.

If you are using the BL51 linker/locater in the default configuration you need to delete the references from the code segment that contains the tables with ?CO?OVL2 ~ (func1, func2). Then you need to add the calls from main to func1 and func2 with main ! (func1, func2):

BL51 OVL2.OBJ OVERLAY (?CO?OVL2~(func1, func2), main!(func1, func2))

The SPEEDOVL control of BL51 ignores all references from constant segments to program code. This is also the operation mode of LX51 and L251. Therefore you need only to add the calls from main to func1 and func2 with main !

(func1, func2):

BL51 OVL2.OBJ OVERLAY (main ! (func1, func2)) SPEEDOVL

The LX51 and L251 linker/locater always ignores the references from constant segments to program code and requires only to add the function calls:

LX51 OVL2.OBJ OVERLAY (main ! (func1, func2))

288 Chapter 9. Linker/Locator