RISC-V反汇编程序与spike运行结果不匹配？答案

【问题标题】：RISC-V disassembler doesn't match with spike running results?RISC-V反汇编程序与spike运行结果不匹配？
【发布时间】：2023-04-09 04:19:01
【问题描述】：

我设置了一个 hello world 程序，仅用于测试我的 riscv32-unknown-elf 工具链、spike、pk 等。虽然我设法使用 spike --isa=RV32 pk hello.elf 打印了 hello world，但我发现如果我为调试添加了-d 标志，我得到了以下说明（整体的一部分）：

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

反正和riscv32-unknown-elf-objdump -d hello.elf > hello.dump产生的反汇编不符（也是开头的一段）：

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

我很困惑，因为地址和机器代码之间存在很大差异。如果您能给我一些想法，我将不胜感激。谢谢！

最好的问候，赛璐珞

【问题讨论】：

首先说这是野兽的本性，这样的指令集可能会因实现而异。获取所有正确的命令行，以便工具与相关目标实现的 isa 对齐。我猜这就像你没有为你正在做的每件事指定相同的目标，或者基本上没有指定相同的目标。
我觉得奇怪的是，我得到了正确的结果，但没有得到预期的机器代码和地址。实际上我的计划是将 C 程序编译成机器代码，稍后我会将其输入到 Xilinx Virtex-5 的 Block RAM 中。所以代码应该与 CPU 一起工作来实现我想要的东西。所以我必须弄清楚哪个代码是正确的。也许我应该把所有这些代码一一放在FPGA中测试？
那么在地址与反汇编和调试器对齐的地方，机器代码是相同还是不同？
不，那完全不同。正如您在上面看到的（第一部分调试器第二个反汇编器）。
objdump 报告虚拟地址；我相信spike只报告物理地址。

标签： gcc assembly compilation riscv disassembly

【解决方案1】：

如果你像这样开始 Spike

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

您的交互式调试会话从代理内核 (pk) 的第一条指令开始，不是在用户空间程序的第一条指令开始。

您通常想要做的是继续执行 pk，然后在程序的第一条指令处中断（请参阅 objdump 输出的起始地址），例如

: until pc 0 10074

然后从那里单步 (ENTER)。

另请参阅 Spike 帮助命令 (h)。

【讨论】：

【解决方案2】：

我认为在尖峰中，您会看到启动过程的开始和 pk 二进制文件（在物理地址中）。在objdump 输出中，您已经从入口点反汇编了 ELF。所以你好二进制可能会在峰值输出的某个地方......

你从 Speak 看到的和我类似的机器初始化代码：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

然后是machine/mentry.S 的精确do_reset（第183 行），它仍然在主pk 代码之前，在加载和运行用户应用程序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

【讨论】：