Once the location counter is initialized, the next statement in the linker script is the declaration of the .text section. This is where all the executable code is expected to be found. The section is declared by specifying its name (.text) followed by a colon (:) and a pair of braces that enclose the statements specific to the current section.

The first statement in the .text section block is a PROVIDE command. This defines a linker symbol that can be used when linking. In this case it defines a global symbol named _text_start which has the current value of the location counter. This symbol can be used to refer to the starting offset of the .text section in memory.

The next statement uses wildcards to aggregate the assembly code in the .text.init section of all object files provided to the linker. The next statement aggregates the code from the .text and .text.* sections in all of the provided object files. The later rule will match any section name prefixed with the .text. substring.

Note that the order in which object files are provided to the linker matters. If the add.o and main.o files are linked with the add function provided first, the resulting binary will have the following layout:

$ riscv64-unknown-elf-ld -T linker.lds -o sum.elf add.o main.o
$ riscv64-unknown-elf-objdump -d sum.elf 

sum.elf:     file format elf64-littleriscv


Disassembly of section .text:

0000000080000000 <sum>:
    80000000:	fe010113          	addi	sp,sp,-32
    80000004:	00113c23          	sd	ra,24(sp)
    80000008:	00b50533          	add	a0,a0,a1
    8000000c:	01813083          	ld	ra,24(sp)
    80000010:	02010113          	addi	sp,sp,32
    80000014:	00008067          	ret

0000000080000018 <_start>:
    80000018:	00500513          	li	a0,5
    8000001c:	00400593          	li	a1,4
    80000020:	00009117          	auipc	sp,0x9
    80000024:	fe010113          	addi	sp,sp,-32 # 80009000 <_stack_end>
    80000028:	fd9ff0ef          	jal	ra,80000000 <sum>

000000008000002c <stop>:
    8000002c:	0000006f          	j	8000002c <stop>

This is clearly not the desired result since the first instruction will create a stack frame, save the return address (which is undefined), then perform the add with un-initialized argument registers. To ensure that the initialization comes before the function implementation, the main.s file must be changed to add its code to the .text.init section:

 1:         .section ".text.init"
 2:         .align 2
 3:         .global _start
 4:         .global _stack_end
 5: _start:
 6:         li      a0, 5
 7:         li      a1, 4
 8:         la      sp,_stack_end
 9:         call    sum
10: stop:   j       stop

The main.s file uses the .section assembler directive on line 1 to declare that all code that follows should be copied into the .text.init section. This will ensure that the initialization code will always be first due to the command to aggregate code from this section preceding any other in the linker script. The linked program will now have the proper layout regardless of the order in which the object files are provided to the linker.

$ riscv64-unknown-elf-ld -T linker.lds -o sum.elf add.o main.o
$ riscv64-unknown-elf-objdump -d sum.elf 

sum.elf:     file format elf64-littleriscv


Disassembly of section .text:

0000000080000000 <_start>:
    80000000:	00500513          	li	a0,5
    80000004:	00400593          	li	a1,4
    80000008:	00009117          	auipc	sp,0x9
    8000000c:	ff810113          	addi	sp,sp,-8 # 80009000 <_stack_end>
    80000010:	008000ef          	jal	ra,80000018 <sum>

0000000080000014 <stop>:
    80000014:	0000006f          	j	80000014 <stop>

0000000080000018 <sum>:
    80000018:	fe010113          	addi	sp,sp,-32
    8000001c:	00113c23          	sd	ra,24(sp)
    80000020:	00b50533          	add	a0,a0,a1
    80000024:	01813083          	ld	ra,24(sp)
    80000028:	02010113          	addi	sp,sp,32
    8000002c:	00008067          	ret

The _start code is located at offset 0x80000000 as expected even if the object file for the sum function was provided to the linker first. Now that the code is properly organized, let's look at the data.

The linker script defines three data sections: .rodata, .data, and .bss. It may seem odd to have four sections (if the .text section is counted) when a program is comprised only of two types on information: code and data. The reason is that data can be divided up into three categories:

• Global Read-only Data
• Global Initialized Data
• Global Un-initialized Data

Local data is not considered because this type of data is generated at run time and will be stored either in stack memory, or some allocated heap buffer. For now the focus will be on global data. The differences in each type of data can be illustrated using a simple C program:

 1: const int operand1 = 4 ;
 2: int operand2 = 5 ;
 3: int result ;
 4: 
 5: int
 6: sum( int op1, int op2 )
 7: {
 8:         return op1 + op2 ;
 9: }
10: 
11: int
12: main( int argc, char** argv )
13: {
14:         result = sum( operand1, operand2 ) ;
15:         while ( 1 ) ;
16: }

The assembly program to add two integer values can be update to read its operands from memory. The following listing shows the updated main.s assembly code:

 1:         .section ".text.init"
 2:         .align 2
 3:         .global _start
 4:         .global _stack_end
 5: _start:
 6:         lw      a0, operand2
 7:         lw      a1, operand1
 8:         la      sp,_stack_end
 9:         call    sum
10:         la      t1, result
11:         sw      a0, 0(t1)
12: stop:   j       stop
13:         .section ".rodata"
14: operand1:       .word   4
15:         .data
16: operand2:       .word   5
17:         .bss
18: result:         .word   0

The value of operand2 is loaded into the function argument register a0 on line 6. The value of operand1 is loaded into the function argument register a1 on line 7. The sum function is called with those operands and the result (stored in a0), is saved in the memory word allocated for result in the .bss section on line 11. Before saving the result, the memory location of the result variable must first be loaded into a register; this is accomplished using the la instruction on line 10.

This program can be assembled and linked with the add.s program as follows:

$ riscv64-unknown-elf-as -o main.o main.s
$ riscv64-unknown-elf-as -o add.o add.s
$ riscv64-unknown-elf-ld -T linker.lds -o sum.elf add.o main.o

The memory offset of the result can be obtained by inspecting the resulting ELF file:

$ riscv64-unknown-elf-objdump -D -j.bss sum.elf 

sum.elf:     file format elf64-littleriscv


Disassembly of section .bss:

0000000080001004 <result>:
    80001004:	0000                	unimp
	...

The program can now be tested using the qemu emulator. Given that the memory location of the result variable is 0x80001004, we can inspect this memory location to ensure that it contains the expected result:

$ qemu-system-riscv64 -M virt -serial /dev/null -nographic -kernel sum.elf
QEMU 3.1.0 monitor - type 'help' for more information
(qemu) xp /1dw 0x80001004
0000000080001004:          9
(qemu) 

The memory location that corresponds with the result variable does in fact contain the value 9 (which is the sum of 4 and 5). Therefore the program is behaving as expected.