RISC-V disassembler doesn't match with spike running results?

▲
2
▼

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

gcc
assembly
compilation
riscv
disassembly
asked on Stack Overflow Jan 24, 2017 by Cy Wang • edited Mar 15, 2017 by osgx

2 Answers

▲
1
▼

If you start Spike like this

spike -d --isa=RV32 pk hello.elf

your interactive debugging session starts at the first instruction of the proxy-kernel (pk) and not at the first instruction of your user-space program.

What you usually want to do is to continue executing the pk and then break on the first instruction of your program (see your objdump output for the start address), e.g.

: until pc 0 10074

and then single step (ENTER) from there.

See also the Spike help command (h).

answered on Stack Overflow Feb 15, 2020 by maxschlepzig
▲
0
▼

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
answered on Stack Overflow Mar 15, 2017 by osgx

User contributions licensed under CC BY-SA 3.0