1. Accueil
  2. Question et réponse
  3. Le désassembleur RISC-V ne correspond pas aux résultats de course de pointe?

Le désassembleur RISC-V ne correspond pas aux résultats de course de pointe?

2017-01-24 3 views
1

J'ai mis en place un programme mondial de bonjour juste pour tester mon riscv32-unknown-elf toolchain, spike, pk etc. Bien que je réussi à obtenir le monde bonjour imprimés à l'aide spike --isa=RV32 pk hello.elf, j'ai découvert que si j'ajouté le drapeau -d pour le débogage, j'étais donné des instructions suivantes (une partie de l'ensemble):Le désassembleur RISC-V ne correspond pas aux résultats de course de pointe?

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

Quoi qu'il en soit, il ne correspond pas à la désassembleur produite à partir riscv32-unknown-elf-objdump -d hello.elf > hello.dump (également une section sur le début):

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

Je suis con fusionné car il y a une grande différence entre les adresses et le code machine. J'apprécierais vraiment si vous pouviez me donner quelques idées. Merci!

Cordialement, Cy

Source

2017-01-24 Cy Wang

+0

en disant que c'est la nature de la bête avec des jeux d'instructions comme celui qui peut varier en fonction la mise en œuvre. Obtenir toutes les bonnes lignes de commande afin que les outils s'alignent avec l'isa implémentée par la cible en question. Je suppose que c'est quelque chose comme ça que vous ne spécifiez pas la même cible pour chaque chose que vous faites, ou que vous ne spécifiez pas la même cible. –

+0

Ce que je trouve bizarre, c'est que j'ai obtenu le bon résultat, mais pas le code machine et les adresses comme prévu. En fait, mon plan est de compiler le programme C en code machine, que j'entrerais dans une RAM de bloc pour Xilinx Virtex-5 plus tard. Et donc le code devrait fonctionner avec le CPU pour mettre en œuvre la chose que je veux. Je dois donc déterminer quel code est correct. Peut-être que je devrais juste mettre tous ces codes un par un pour tester en FPGA? –

+0

donc dans les endroits où les adresses s'alignent à partir du désassemblage et du débogueur est le code machine le même ou différent? –

Répondre

0

Je pense que vous voyez pic début du processus de démarrage et le pk binaire (en adresses physiques). Et dans objdump sortie vous avez ELF démonté du point d'entrée. Donc bonjour binaire peut être quelque part plus tard dans la sortie pic ...

Ce que vous voyez de pic me ressemble ce code de la machine 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

puis exacte de machine/mentry.S (ligne 183), il est toujours avant code principal pk, avant l'application utilisateur chargement et l'exécution hello:

début mal 
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

Source

2017-03-15 02:37:09 osgx

 Questions connexes

  • Aucun problème connexe^_^