The linker is responsible for combining multiple object files into a single ELF executable. In order to create a single ELF executable, it resolves cross- references between the different object files, groups together similar sections into one contiguous location, arranges for these sections to be loaded at the correct addresses in memory, and generates the necessary header
information at the start of a file that allows it to be run.
Some sections in a LatticeMico ELF executable are predefined and hold specific program information. The most critical of these sections, at least from a software developer’s perspective, are discussed below.
.text This section contains program instructions that will be executed by the microprocessor. This section can be configured for one of three scenarios: Load and execute in volatile memory
Load and execute in non-volatile memory
Load in non-volatile memory and execute in volatile memory.
.rodata This section contains read-only data, which means that the data is not modified by the executable at runtime. This section can be configured for one of three scenarios:
ADVANCED PROGRAMMING TOPICS : Linker Script and Memory Sections
Load in non-volatile memory and execute in volatile memory. .bss This section contains read/write data that is initialized to zero at runtime. This section can be configured for one of two scenarios: Load and execute in volatile memory
Load in non-volatile memory and execute in volatile memory.
.data This section contains initialized (non-zero) data that is modifiable at run time. This section can be configured for one of two scenarios:
Load and execute in volatile memory
Load in non-volatile memory and execute in volatile memory.
In addition, the program might contain a stack that is used to store register values across function calls. Of all the aforementioned sections, the
LatticeMico C/C++ SPE managed build process allows a software developer to select the memory locations for the placement of ELF sections .text, .rodata, and .data. There are two memory addresses associated with these three sections. The first is the virtual memory address (VMA), which is the address the section will have when the executable is running. The second is the load memory address (LMA), which is the address in memory where the section will be loaded. In most cases, the two addresses will be the same. An example of when they might be different is when a data section is loaded into ROM and then copied in to RAM when the program starts executing. In this case, the ROM address would be the LMA and the RAM address would be the VMA.
You can use the lm32-elf-objdump utility to obtain information on various sections and their placements. See “IRunning the Software from the Command Line” on page 42 and Table 26 on page 294 for usage and valid options for the lm32-elf-objdump utility.
The LatticeMico C/C++ managed build process generates a default linker script, linker.ld, that encapsulates the user-provided placement information for the .text, .rodata, and .data sections of the executable. The placement of the .boot and .bss sections is still controlled by the managed build process to ensure that a valid executable is created by the linker script.
Table 16 on page 177 shows an example that articulates the legal placement combinations for .text, .rodata, and .data sections, the subsequent placement of .boot and .bss sections, and the "Linker Script" GUI settings that the user must manipulate to achieve the required placement for these sections.
ADVANCED PROGRAMMING TOPICS : Linker Script and Memory Sections
1 Make sure that you use On-chip Memory Deployment or Multi On-chip Memory Deployment to ensure .rodata and .data are deployed in to RAM.
2 It is not advisable to use this combination, since ROM is a non-volatile memory and a location holding .data value must be erased prior to any write.
The C/C++ SPE allows you to select a custom linker script for the software project through the Platform tab available in the Properties dialog box when you right-click on the software project in the Projects view. See Figure 141 on page 191 for details. You can use the default linker script generated by LatticeMico C/C++ SPE managed build process as a starting point for your custom linker script.
Table 16: Example of Legal Placement Combinations
Location of Program Sections (under user control)
Location of Program Sections
(NOT under user control) User Interface
.text
.rodata or
.data .boot .bss Deploy Flag
VMA LMA VMA LMA Note VMA LMA VMA LMA Program
RO or RW Data Enable Deploy- ment Program RO or RW Data
RAM RAM RAM RAM RAM RAM RAM RAM RAM RAM N N/A N/A
RAM ROM RAM RAM 1 ROM ROM RAM RAM RAM RAM Y Y N
ROM ROM RAM RAM 1 ROM ROM RAM RAM ROM RAM Y Y Y
RAM ROM RAM ROM ROM ROM RAM RAM RAM RAM Y Y Y
ROM ROM RAM ROM ROM ROM RAM RAM ROM RAM Y Y Y
ROM ROM ROM ROM 2 ‘ROM ROM RAM RAM ROM ROM Y Y Y
Note
To make sure the microprocessor starts executing your code on power-up, be sure to set the exception base address (EBA) to the LMA of the .text section.
Note
The software for copying the data section from ROM to RAM is located in the .boot section (crt0ram.S). If the software developer is creating an application executable and corresponding custom linker script that contain any sections other than the default sections (.boot, .text, .data, .rodata, and .bss), the developer must modify crt0ram.S in addition to providing a custom linker script.
ADVANCED PROGRAMMING TOPICS : Software Deployment