4. Linker

The linker comes with the GNU binutils package. It is responsible for collecting the object files together, map the code in memory and create the final executable.

This chapter presents some details about using the GNU linker for 68HC11 and 68HC12. The GNU ld documentation is probably more complete. The GNU binutils contain the assembler, linker, archiver and many other utilities. These utilities use various format for object files including ELF-32, Motorola S-records, Intel HEX records, and others.

The complete GNU Linker documentation is available in The GNU Linker and other utility tools are described in The GNU Binary Utilities.

4.1 Object Files

Gas generates object files in the ELF format. The specific tags EM_68HC11 (70) and EM_68HC12 (53) are used to identify the machine. These tags are defined by the `Motorola Embedded Working Group' (see http://www.mcu.motsps.com/dev_tools/hc12/eabi. Gas generates the following relocation types:

• 8-bit PCREL

• 8-bit absolute

• 8-bit low address part (no complain on overflow)

• 8-bit high address part

• 16-bit PCREL

• 16-bit absolute

• branch instruction marks

4.2 Sections

This section presents the important ELF sections that an object file can contain. Each of them play an important role for building the final application.

.text

This is the standard text section for code program. It contains the 68HC11 or 68HC12 binary code. By default, the linker places the text at 0x8000. This can be overridden with `-Ttext' option or better by specifying a text memory region.

.rodata

This is the standard read-only data section. It is placed after the text section by the linker. The compiler uses this section to store constant values like strings, jump tables.

.data

This is the standard data section. It is used for initialized global and static variables.

.bss

This is the standard bss section. It appears after the data section. It is used for non-initialized global and static variables.

.page0

This is a specific section for the 68HC11 and 68HC12 to represent the page 0. It is intended to be used to help in specifying data which are defined in the first 256-bytes (page 0) of the address space. It is placed at address 0 by the linker. It is treated as a .data section.

.eeprom

This is a specific section for the 68HC11 and 68HC12 to represent the internal EEPROM.

.install[0-4]

These sections represent some initialization sections. They are used by the GCC startup code. Some of them are for used by applications. During the final link, these sections are merged with the `.text' section, and are put at beginning of the program. Therefore, they appear at beginning of ROM area. The `.install0' is reserved. It initializes the stack pointer. The `.install1' is a placeholder for applications. The `.install2' is reserved. It initializes the bss and data sections. The `.install3' is a placeholder for applications. The `.install4' is reserved and invokes the main.

.fini[0-4]

These sections represent some termination sections. They are used by the GCC finish code (`exit'). Some of them are for use by applications. During the final link, these sections are merged with the `.text' section. `.fini0' and `.fini4' are reserved. `.fini1' is a placeholder for applications. It can contain code which is executed during exit and before the C++ static destructors. `.fini2' is reserved and corresponds to the C++ static destructors. `.fini3' is a placeholder for applications. This code is executed after the C++ static destructors are called. The `.fini4' is reserved and corresponds to the runtime exit.

.vectors

This is a specific section for the 68HC1x to represent the vectors table. By default the vectors table is located at 0xffc0 and placed at that address by the linker. By using the `-defsym vectors_addr=addr' linker option, it is possible to set another address for the vectors table. For example, `-defsym vectors_addr=0xbfc0' sets the vectors table at 0xbfc0.

.softregs

This is a specific section for the 68HC11 and 68HC12 to hold the gcc soft registers. For 68HC11, this section is put during the final link in the `.page0' section. For 68HC12, it is put in the `.bss' section.

others

Several standard sections exists for DWARF-2 debugging info, stack frame unwinding description and so on.

4.3 Linker Memory Banks

The Linker contains built-in linker scripts which indicate how to perform the link and where to put the different sections. You can use the provided linker scripts or write yours. In general, you will want to give the linker some information about the ROM and RAM you have on your board. The Linker defines two emulations which allow you to use one

The `m68hc11elf' and `m68hc12elf' emulations define the memory as follows:

MEMORY { page0 (rwx) : ORIGIN = 0x0, LENGTH = 256 text (rx) : ORIGIN = 0x08000, LENGTH = 0x8000 data : ORIGIN = 0x01100, LENGTH = 0x6F00 eeprom : ORIGIN = 0xb600, LENGTH = 512 } PROVIDE (_stack = 0x1100 + 0x6f00 - 1);

which means that there are two RAM banks, one at [0x0..0xff] and one at [0x1100..0x7fff]. There is also a ROM bank at [0x8000..0xffff]. The PROVIDE instruction defines the address of the top of the stack to the top of the RAM. This memory configuration is suitable for the 68HC11/68HC12 simulator. It was defined like this to be able to run the GCC test-suite.

The `m68hc11elfb' and `m68hc12elfb' emulations are the same except that they include a file `memory.x' that you must provide in the current directory or in one of the `-L' directories. The file you have to write must contain the above MEMORY definition. You can change the address and sizes of the different memory banks. You must also define the address of the top of the stack.

To select a particular linker emulation, use the `-m emulation' option. If you use m6811-elf-gcc or m6812-elf-gcc, you must pass the emulation through the `-Xlinker' or `-Wl' option. For example:

m6811-elf-gcc -Wl,-m,m68hc11elfb -o tst.out tst.o

When you specify a linker emulation through the `-Wl,-m' option, you must be careful to use the emulation that corresponds to your CPU target. If you compiled your program with -m68hc12 or -m68hcs12 you should use the `m68hc12elfb' emulation.

4.4 Ld Symbols

The Linker uses and provides some symbols that you can use in your program.

_start

This symbol represents the entry point of the program. It is provided by the GCC startup file and it is used by the linker to know the entry point of the program. The linker script is configured to try to put this symbol at beginning of the ROM area.

_stack

This symbol represents the top of the stack. It is computed by the linker to refer to the top of the data memory bank. The GCC startup file sets the stack pointer to this value at beginning.

etext

This symbol represents the end address of the `.text' section.

edata

This symbol represents the end address of the `.data' section.

__data_image

This symbol represents the starting address of the ROM area which contains the copy of initialized data. These data must be copied from ROM to RAM during initialization. This is done by the GCC startup file.

__data_image_end

This symbol is: `__data_image + __data_section_size'.

__data_section_start

This symbol represents the starting address of the data section in RAM.

This symbol should rather be named: `__data_start'.

__data_section_size

This symbol represents the size in bytes of the data section that must be copied from ROM to RAM.

This symbol should rather be named: `__data_size'.

__bss_start

This symbol represents the starting address of the BSS section in RAM. This is also the end of the data section.

__bss_size

This symbol represents the size in bytes of the BSS section. Together with `__bss_start' it is used to initialize the BSS section at startup time.

_end

This symbol represents the ending address of the BSS section in RAM.

_vectors_addr

This symbol represents the starting address of the 68HC11/68HC12 vector's table. The default value is 0xffc0. If you have provided a `-defsym vectors_addr=addr' option to the linker, this symbol will have the value you have specified.

Note: If you provide a `vectors_addr' symbol, there will be two symbols: one with _ and one without.