I've set up a hello world program just for testing my riscv32-unknown-elf toolchain, spike, pk etc. Though I managed to get the hello world printed using spike --isa=RV32 pk hello.elf, I found out that if I added the -d flag for debugging, I was given following instructions (a section of the whole):
core 0: 0x0000000000001000 (0x7ffff297) auipc t0, 0x7ffff
:
core 0: 0x0000000000001004 (0x00028067) jr t0
:
core 0: 0xffffffff80000000 (0x1b00006f) j pc + 0x1b0
:
core 0: 0xffffffff800001b0 (0x00000093) li ra, 0
:
core 0: 0xffffffff800001b4 (0x00000113) li sp, 0
:
core 0: 0xffffffff800001b8 (0x00000193) li gp, 0
:
core 0: 0xffffffff800001bc (0x00000213) li tp, 0
:
core 0: 0xffffffff800001c0 (0x00000293) li t0, 0
:
core 0: 0xffffffff800001c4 (0x00000313) li t1, 0
:
core 0: 0xffffffff800001c8 (0x00000393) li t2, 0
:
core 0: 0xffffffff800001cc (0x00000413) li s0, 0
:
core 0: 0xffffffff800001d0 (0x00000493) li s1, 0
:
core 0: 0xffffffff800001d4 (0x00000513) li a0, 0
:
core 0: 0xffffffff800001d8 (0x00000593) li a1, 0
:
core 0: 0xffffffff800001dc (0x00000613) li a2, 0
:
core 0: 0xffffffff800001e0 (0x00000693) li a3, 0
:
core 0: 0xffffffff800001e4 (0x00000713) li a4, 0
:
core 0: 0xffffffff800001e8 (0x00000793) li a5, 0
:
core 0: 0xffffffff800001ec (0x00000813) li a6, 0
:
core 0: 0xffffffff800001f0 (0x00000893) li a7, 0
:
core 0: 0xffffffff800001f4 (0x00000913) li s2, 0
:
core 0: 0xffffffff800001f8 (0x00000993) li s3, 0
:
core 0: 0xffffffff800001fc (0x00000a13) li s4, 0
:
core 0: 0xffffffff80000200 (0x00000a93) li s5, 0
:
core 0: 0xffffffff80000204 (0x00000b13) li s6, 0
:
core 0: 0xffffffff80000208 (0x00000b93) li s7, 0
:
core 0: 0xffffffff8000020c (0x00000c13) li s8, 0
:
core 0: 0xffffffff80000210 (0x00000c93) li s9, 0
:
core 0: 0xffffffff80000214 (0x00000d13) li s10, 0
:
core 0: 0xffffffff80000218 (0x00000d93) li s11, 0
:
core 0: 0xffffffff8000021c (0x00000e13) li t3, 0
:
core 0: 0xffffffff80000220 (0x00000e93) li t4, 0
:
core 0: 0xffffffff80000224 (0x00000f13) li t5, 0
:
core 0: 0xffffffff80000228 (0x00000f93) li t6, 0
:
core 0: 0xffffffff8000022c (0x34001073) csrw mscratch, zero
:
core 0: 0xffffffff80000230 (0x00000297) auipc t0, 0x0
:
core 0: 0xffffffff80000234 (0xdd828293) addi t0, t0, -552
:
core 0: 0xffffffff80000238 (0x30529073) csrw mtvec, t0
:
core 0: 0xffffffff8000023c (0x30502373) csrr t1, mtvec
:
core 0: 0xffffffff80000240 (0x00629063) bne t0, t1, pc + 0
:
core 0: 0xffffffff80000244 (0x00012117) auipc sp, 0x12
Anyway it doesn't match the disassembler produced from riscv32-unknown-elf-objdump -d hello.elf > hello.dump (also a section on the beginning):
hello.elf: file format elf32-littleriscv
Disassembly of section .text:
00010074 <_start>:
10074: 00005197 auipc gp,0x5
10078: fcc18193 addi gp,gp,-52 # 15040 <_gp>
1007c: 00004517 auipc a0,0x4
10080: 7d850513 addi a0,a0,2008 # 14854 <_edata>
10084: 00005617 auipc a2,0x5
10088: 83060613 addi a2,a2,-2000 # 148b4 <_end>
1008c: 40a60633 sub a2,a2,a0
10090: 00000593 li a1,0
10094: 2c0000ef jal ra,10354 <memset>
10098: 00000517 auipc a0,0x0
1009c: 1bc50513 addi a0,a0,444 # 10254 <__libc_fini_array>
100a0: 16c000ef jal ra,1020c <atexit>
100a4: 210000ef jal ra,102b4 <__libc_init_array>
100a8: 00012503 lw a0,0(sp)
100ac: 00410593 addi a1,sp,4
100b0: 00000613 li a2,0
100b4: 124000ef jal ra,101d8 <main>
100b8: 1680006f j 10220 <exit>
000100bc <_fini>:
100bc: 00008067 ret
000100c0 <deregister_tm_clones>:
100c0: 00015537 lui a0,0x15
100c4: 000157b7 lui a5,0x15
100c8: 84050713 addi a4,a0,-1984 # 14840 <__TMC_END__>
100cc: 84378793 addi a5,a5,-1981 # 14843 <__TMC_END__+0x3>
100d0: 40e787b3 sub a5,a5,a4
100d4: 00600713 li a4,6
100d8: 00f77c63 bleu a5,a4,100f0 <deregister_tm_clones+0x30>
100dc: 00000337 lui t1,0x0
100e0: 00030313 mv t1,t1
100e4: 00030663 beqz t1,100f0 <deregister_tm_clones+0x30>
100e8: 84050513 addi a0,a0,-1984
100ec: 00030067 jr t1
100f0: 00008067 ret
000100f4 <register_tm_clones>:
100f4: 00015537 lui a0,0x15
100f8: 000155b7 lui a1,0x15
100fc: 84050793 addi a5,a0,-1984 # 14840 <__TMC_END__>
10100: 84058593 addi a1,a1,-1984 # 14840 <__TMC_END__>
10104: 40f585b3 sub a1,a1,a5
10108: 4025d593 srai a1,a1,0x2
1010c: 01f5d793 srli a5,a1,0x1f
10110: 00b785b3 add a1,a5,a1
10114: 4015d593 srai a1,a1,0x1
10118: 00058c63 beqz a1,10130 <register_tm_clones+0x3c>
1011c: 00000337 lui t1,0x0
10120: 00030313 mv t1,t1
10124: 00030663 beqz t1,10130 <register_tm_clones+0x3c>
10128: 84050513 addi a0,a0,-1984
1012c: 00030067 jr t1
10130: 00008067 ret
I am confused since there's a big difference between both the addresses and machine code. I'd really appreciate it if you could give me some thoughts. Thanks!
Best regards, Cy
I think that in spike you see start of boot process and the pk binary (in physical addresses). And in objdump output you have ELF disassembled from the entry point. So hello binary may be somewhere later in spike output...
What you see from spike resemble me this code of machine init: https://github.com/riscv/riscv-pk/blob/6c1d0604dcabf36a6a8d8d9a839b2d4634e202d2/machine/mentry.S#L183
core 0: 0x0000000000001000 (0x7ffff297) auipc t0, 0x7ffff
:
core 0: 0x0000000000001004 (0x00028067) jr t0
reset_vector:
j do_reset
and then exact do_reset of machine/mentry.S (line 183), it is still before main pk code, before loading and running user app hello:
do_reset:
li x1, 0
li x2, 0
li x3, 0
li x4, 0
li x5, 0
li x6, 0
li x7, 0
li x8, 0
li x9, 0
li x10, 0
li x11, 0
li x12, 0
li x13, 0
li x14, 0
li x15, 0
li x16, 0
li x17, 0
li x18, 0
li x19, 0
li x20, 0
li x21, 0
li x22, 0
li x23, 0
li x24, 0
li x25, 0
li x26, 0
li x27, 0
li x28, 0
li x29, 0
li x30, 0
li x31, 0
csrw mscratch, x0
# write mtvec and make sure it sticks
la t0, trap_vector
csrw mtvec, t0
csrr t1, mtvec
1:bne t0, t1, 1b
来源：https://stackoverflow.com/questions/41817881/risc-v-disassembler-doesnt-match-with-spike-running-results