Gcc RISC-V反汇编程序不'；与扣球成绩不匹配？

我已经建立了一个hello world程序，只是为了测试我的

riscv32 unknown elf

工具链、

spike

、

pk

等。尽管我设法使用

spike--isa=RV32 pk hello.elf

打印了hello world，但我发现如果我添加了

-d

标志进行调试，我会得到以下指示（全文的一节）：

无论如何，它与从

riscv32 unknown elf objdump-d hello.elf>hello.dump生成的反汇编程序不匹配（也是开始部分）：

hello.elf:文件格式elf32 littleriscv
第节的分解。正文：
00010074 :   
10074:00005197 auipc总成，0x5
10078:fcc18193附加总成，总成，-52#15040
1007c:00004517 auipc a0,0x4
10080:7d850513 addi a0，A02008#14854
10084:00005617 auipc a2,0x5
10088:83060613 addi a2，a2，-2000#148b4
1008c:40a60633子a2、a2、a0
10090:00000593 li a1,0
10094:2c0000ef日本航空公司，邮编10354
10098:00000517 auipc a0,0x0
1009c:1bc50513 addi a0、A0444#10254
100a0:16c000ef日本航空公司，1020c
100a4:210000ef日航，102b4
100a8:00012503 lw a0,0（sp）
100ac:00410593 addi a1，sp，4
100b0:00000613 li a2,0
100b4:124000ef日航，101d8
100b8:1680006f j 10220
公元前000100年：
公元前100年：00008067
000100c0：
100c0:00015537 lui a0,0x15
100c4:000157b7 lui a5,0x15
100c8:84050713 addi a4，a0，-1984#14840
100cc:84378793 addi a5，a5，-1981#14843
100d0:40e787b3接头a5、a5、a4
100d4:00600713 li a4,6
100d8:00f77c63 bleu a5，A4100F0
100dc:00000337 lui t1,0x0
100e0:00030313 mv t1，t1
100e4:00030663 beqz T1100F0
100e8:84050513 addi a0，a0，-1984
100ec:00030067 jr t1
100f0:00008067 ret
000100f4：
100f4:00015537 lui a0,0x15
100f8:000155b7 lui a1,0x15
100fc:84050793 addi a5，a0，-1984#14840
10100:84058593 addi a1，a1，-1984#14840
10104:40f585b3接头a1、a1、a5
10108:4025d593 srai a1，a1,0x2
1010c:01f5d793 srli a5，a1,0x1f
10110:00b785b3添加a1、a5、a1
10114:4015d593 srai a1，a1,0x1
10118:00058c63 beqz A110130
1011c:00000337 lui t1,0x0
10120:00030313 mv t1，t1
10124:00030663贝基兹T110130
10128:84050513 addi a0，a0，-1984
1012c:00030067 jr t1
10130:00008067 ret

我很困惑，因为地址和机器代码之间有很大的差异。如果你能给我一些想法，我将非常感激。谢谢

致以最良好的祝愿，
Cy
我认为在spike中，您可以看到启动过程的开始和
pk
二进制文件（在物理地址中）。在
objdump
输出中，您可以从入口点反汇编ELF。因此，hello二进制文件可能稍后会出现在spike输出中

你从spike身上看到的类似于我机器初始化的代码：

然后在加载和运行用户应用程序之前，对机器/mentry.S

（第183行）执行精确的重置，它仍然在main

pk

代码之前：

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

---

如果你开始这样扣球

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

交互式调试会话从代理内核（pk）的第一条指令开始，而不是从用户空间程序的第一条指令开始

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

然后从那里开始一步（进入）

---

另请参见Spike help命令（

h

）.

我首先要说的是，这是beast的本质，它的指令集可能会因实现的不同而有所不同。获取所有正确的命令行，使工具与目标实现的isa保持一致。我猜这可能是因为你没有为你正在做的每件事指定相同的目标，或者基本的目标ally没有指定相同的目标。我觉得奇怪的是，我得到了正确的结果，但没有得到预期的机器代码和地址。实际上，我的计划是将C程序编译成机器代码，然后输入到Xilinx Virtex-5的块RAM中。因此，代码应该与CPU一起实现我想要的东西。所以我必须找出哪个代码是正确的。也许我应该把所有这些代码一个接一个地放在FPGA中进行测试？那么，在地址从反汇编和调试器排列的地方，机器代码是相同的还是不同的？不，这是完全不同的。如上所述（第一部分调试器第二部分反汇编程序）.objdump报告虚拟地址；我相信spike只报告物理地址。

core   0: 0x0000000000001000 (0x7ffff297) auipc   t0, 0x7ffff
:  
core   0: 0x0000000000001004 (0x00028067) jr      t0

reset_vector:
  j do_reset

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

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

: until pc 0 10074