|Home > Overlays > Automatic overlay support > Writing an overlay manager for automatically placed overlays|
To write an overlay manager to handle loading and unloading of overlays, you must provide an implementation of the overlay manager entry point.
__ARM_overlay_entryis the location that the linker-generated veneers expect to jump to. The linker also provides some tables of data to enable the overlay manager to find the overlays and the overlay regions to load.
The entry point is called by the linker overlay veneers as follows:
BL, the value of lr is the one written into lr by the
BLinstruction, not the one before the
The overlay manager has to:
The overlay manager might also have to modify the value it passes to the calling function in lr to point at a return thunk routine. This routine would reload the overlay of the calling function and then return control to the original value of the lr of the calling function.
There is no sensible place already available to store the original value of lr for the return thunk to use. For example, there is nowhere on the stack that can contain the value. Therefore, the overlay manager has to maintain its own stack-organized data structure. The data structure contains the saved lr value and the corresponding overlay ID for each time the overlay manager substitutes a return thunk during a function call, and keeps it synchronized with the main call stack.
option causes the linker to write out a text summary of the overlays in the image it
outputs. The summary consists of the integer ID, start address, and size of each
overlay. You can use this information to extract the overlays from the image,
perhaps from the
fromelf --bin output. You can then put them in a
separate peripheral storage system. Therefore, you still know which chunk of data
goes with which overlay ID when you have to load one of them in the overlay