I am trying to create a RISC-V based ZSBL.
The problem I’m having is that ELF .text
section disappears as long as the address ends with 0
, e.g. 0x300000
, 0x3000100
, etc. Why?
When the address is 0x2000000001
, the output of readelf
has .text
section.
$riscv64-unknown-elf-as -c zsbl_cp_jmp.S -o zsbl_cp_jmp.o
$riscv64-unknown-elf-ld -Ttext 0x2000000001 -nostdlib zsbl_cp_jmp.o -o zsbl_cp_jmp.elf
There are 7 section headers, starting at offset 0x11e8:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 0000002000000001 001001 000003 00 AX 0 0 1
[ 2] .init PROGBITS 00000000000100b0 0000b0 00004c 00 AX 0 0 1
[ 3] .riscv.attributes RISCV_ATTRIBUTES 0000000000000000 001004 00002e 00 0 0 1
[ 4] .symtab SYMTAB 0000000000000000 001038 000120 18 5 4 8
[ 5] .strtab STRTAB 0000000000000000 001158 000056 00 0 0 1
[ 6] .shstrtab STRTAB 0000000000000000 0011ae 000039 00 0 0 1
When the address is 0x2000000000
, the.text
section disappears.
$riscv64-unknown-elf-ld -Ttext 0x2000000000 -nostdlib zsbl_cp_jmp.o -o zsbl_cp_jmp.elf
There are 6 section headers, starting at offset 0x290:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .init PROGBITS 0000000000010078 000078 00004c 00 AX 0 0 1
[ 2] .riscv.attributes RISCV_ATTRIBUTES 0000000000000000 0000c4 00002e 00 0 0 1
[ 3] .symtab SYMTAB 0000000000000000 0000f8 000108 18 4 3 8
[ 4] .strtab STRTAB 0000000000000000 000200 000056 00 0 0 1
[ 5] .shstrtab STRTAB 0000000000000000 000256 000033 00 0 0 1
The source code is
.section .init
.global _start
_start:
li a0, 0x2000010000
li a1, 0x2000030000
li a2, 0x20000
li t0, 0
1:
bge t0, a2, 1f
add t1, a1, t0
lb t1, 0(t1)
add t2, a0, t0
sb t1, 0(t2)
addi t0, t0, 1
j 1b
1:
li t3, 0x2000010000
jr t3
The assembly code you’re showing doesn’t have a
.text
section.It’s interesting that specifying an odd address makes a section appear in the linked binary that wasn’t present in the
.o
input. It has a size big enough to get to the next 4-byte alignment boundary, so probably the default linker script ends up emitting some padding. Like maybe the default linker script mentions.text
enough that it has to get “optimized away” if empty.@ErikEidt In my understanding, if you set
-Ttext
, the.text
section will appear. Is this understanding correct? If it’s not correct, how can we explain why.text
section appears when the address is an odd number?e.g.0x2000000001
Maybe try putting a non-zero length
.text
section in the input and let us know what happens.[guessing] The padding required for the odd address is forcing a size of 3 bytes for the section which would otherwise be empty. With the even address, the empty section is eliminated. Perhaps this is what @PeterCordes already said.