[英]RISC-V disassembler doesn't match with spike running results?
我已经设置了一个 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
我很困惑,因为地址和机器代码之间存在很大差异。 如果您能给我一些想法,我将不胜感激。 谢谢!
最好的问候, Cy
如果你这样启动 Spike
spike -d --isa=RV32 pk hello.elf
您的交互式调试会话从代理内核 (pk) 的第一条指令开始,而不是从用户空间程序的第一条指令开始。
您通常想要做的是继续执行 pk,然后在程序的第一条指令处中断(请参阅您的 objdump 输出以获取起始地址),例如
: until pc 0 10074
然后从那里单步( ENTER )。
另请参阅 Spike 帮助命令 ( h
)。
我认为在spike 中你会看到启动过程和pk
二进制文件(在物理地址中)。 在objdump
输出中,您已经从入口点反汇编了 ELF。 所以你好二进制文件可能会出现在尖峰输出中的某个地方......
你从spike看到的类似于我这个机器初始化代码: 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
(第 183 行)的精确do_reset
,它仍然在主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
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.