gcc - sifive - El desensamblador RISC-V no concuerda con los resultados de funcionamiento de pico?

rocket risc v

Question

He creado un programa de hello world solo para probar mi riscv32-unknown-elf , spike , pk , etc. Aunque logré obtener el mundo de Hello impreso con spike --isa=RV32 pk hello.elf , descubrí que si agregué el indicador -d para la depuración, me dieron las siguientes instrucciones (una sección del conjunto):

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

De todos modos, no coincide con el desensamblador producido de riscv32-unknown-elf-objdump -d hello.elf > hello.dump (también una sección al principio):

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 

Estoy confundido ya que hay una gran diferencia entre las direcciones y el código de la máquina. Realmente apreciaría si pudieras darme algunos pensamientos. ¡Gracias!

Saludos cordiales, Cy

Answer 1

Creo que en spike se ve el inicio del proceso de arranque y el binario pk (en las direcciones físicas). Y en la salida objdump tiene ELF desmontado desde el punto de entrada. Así que hola binario puede estar en algún lugar más adelante en la producción de picos ...

Lo que se ve desde el pico me recuerda a este código de máquina 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

y a continuación, do_reset de machine/mentry.S (línea 183), aún antes del código pk principal, antes de cargar y ejecutar la aplicación del usuario 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