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