Разборник RISC-V не соответствует результатам всплеска?

Я создал привет мира программу только для тестирования моих riscv32-unknown-elf набора инструментов, spike, pk и т.д. Хотя мне удалось получить мир привета, напечатанных с помощью spike --isa=RV32 pk hello.elf, я обнаружил, что если я добавил -d флаг для отладки, я был даны следующие инструкции (раздел в целом):Разборник RISC-V не соответствует результатам всплеска?

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

источник

2017-01-24 Cy Wang

плохого начала, говоря, что это природа зверя с наборами команд, как, что это может варьироваться в зависимости от реализации. Получение всех правильных командных строк, чтобы инструменты выстраивались в линию с помощью isa, реализованного объектом, о котором идет речь. Я предполагаю, что это что-то вроде того, что вы не указываете цель одинаково для каждой вещи, которую вы делаете, или в основном не указывая одну и ту же цель. –

Что мне кажется странным, я получил правильный результат, но не машинный код и адреса, как ожидалось. Фактически, мой план состоит в том, чтобы скомпилировать программу C в машинный код, который я буду вводить в Блок-память для Xilinx Virtex-5 позже. И поэтому код должен работать с ЦП для реализации того, что я хочу. Поэтому я должен выяснить, какой код правильный. Может быть, я должен просто поместить все эти коды один за другим, чтобы протестировать в FPGA? –

, так что в местах, где адреса выходят из разборки и из отладчика, это машинный код тот же или другой? –

Я думаю, что в шип вы видите начало процесса загрузки и pk бинарной (в физических адресах). И в выводе objdump у вас есть ELF, разобранный из точки входа. Так привет двоичная может быть где-то в конце шипа выход ...

Что вы видите из колоса похожи на меня этот код машины 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

, а затем точным из machine/mentry.S (строка 183), его еще перед главным 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

источник

2017-03-15 02:37:09 osgx

Разборник RISC-V не соответствует результатам всплеска?

ответ

Смежные вопросы