Add:
- most of instructions from RVI base instructions set.
- some instruction decode tests from objdump.
Further work:
- implement riscv imac extension.
Differential D132789
[LLDB][RISCV] Add more instruction decode and execute for EmulateInstructionRISCV Emmmer on Aug 27 2022, 8:02 AM. Authored by
Details Add:
Further work:
Diff Detail
Event TimelineComment Actions Upon this change, My lldb logging changes a bit. The instruction is not shown anymore, but stepping is still working. Is it as expected? * thread #1, name = 'test.o', stop reason = signal SIGSTOP frame #0: 0x0000000000010528
Comment Actions I tried to reproduce but failed. Comment Actions Sure. My testing script is: #include<stdio.h> void fun2() { printf("Enter fun2\n"); } int fun1() { printf("Enter fun1\n"); fun2(); return 10;} int main(int argc, char **argv) { int a = fun1(); int b = 15; printf("hello world\n"); return 0; } So which file format should be used for debugging? My command option on the client side is: lldb-server g 0.0.0.0:2345 test.o On the lldb (x86) side is: lldb gdb-remote 2345 s The objdump of my test.o file is: 0000000000010528 <_start>: 10528: 02e000ef jal ra,10556 <load_gp> 1052c: 87aa mv a5,a0 1052e: 00000517 auipc a0,0x0 10532: 14650513 addi a0,a0,326 # 10674 <main> 10536: 6582 ld a1,0(sp) 10538: 0030 addi a2,sp,8 1053a: ff017113 andi sp,sp,-16 1053e: 00000697 auipc a3,0x0 10542: 68068693 addi a3,a3,1664 # 10bbe <__libc_csu_init> 10546: 00000717 auipc a4,0x0 My compilation flavor should be: riscv64-unknown-linux-gnu-gcc -g -o test.o hello.c \ -static -static-libgcc -static-libstdc++ -march=rv64imafd Please let me know if you need more information! Comment Actions I coiped your test code to tzb.c (on x86) $ riscv64-unknown-linux-gnu-gcc -g -o tzb tzb.c \ -static -static-libgcc -static-libstdc++ -march=rv64imafd PS: -o usage is: -o <file>, it means place the output into <file>. (on qemu-system-riscv64) $ lldb (lldb) gdb-remote 8888 (lldb) Process 5933 stopped * thread #1, name = 'tzb', stop reason = signal SIGSTOP frame #0: 0x0000000000010528 tzb`_start at start.S:50 warning: This version of LLDB has no plugin for the language "assembler". Inspection of frame variables will be limited. Then I tried to read DWARF in tzb, and dwarfdump report DW_AT_language is DW_LANG_Mips_Assembler, but DW_AT_language should be DW_LANG_C99. It may be a bug caused by riscv-gnu-toolchain, and we can use this to avoid it. (on qemu-system-riscv64) $ gcc -g -o tzb tzb.c \ -static -static-libgcc -static-libstdc++ -march=rv64imafd $ lldb-server g 0.0.0.0:2345 tzb Launched 'tzb' as process 6839... lldb-server-local_build (Switch to another tab) $ lldb (lldb) gdb-remote 2345 (lldb) Process 6839 stopped * thread #1, name = 'tzb', stop reason = signal SIGSTOP frame #0: 0x0000000000010584 tzb`_start tzb`_start: -> 0x10584 <+0>: jal 48 <--| 0x10588 <+4>: mv a5, a0 <--| 0x1058c <+8>: auipc a0, 121 <--| 0x10590 <+12>: ld a0, -980(a0) <--| as expected (lldb) Then you can set breakpoints and go to where you want. I copied some DWARF info that may be useful: in cross-build elf file: .debug_info COMPILE_UNIT<header overall offset = 0x00000000>: < 0><0x0000000c> DW_TAG_compile_unit DW_AT_stmt_list 0x00000000 DW_AT_low_pc 0x00010528 DW_AT_high_pc <offset-from-lowpc>0x00000042 DW_AT_name ../sysdeps/riscv/start.S DW_AT_comp_dir /home/emmmer/git/riscv-gnu-toolchain/glibc/csu DW_AT_producer GNU AS 2.38 DW_AT_language DW_LANG_Mips_Assembler in native-build elf file: .debug_info COMPILE_UNIT<header overall offset = 0x00000000>: < 0><0x0000000b> DW_TAG_compile_unit DW_AT_producer GNU C17 10.3.1 -march=rv64imafd -mabi=lp64d -g DW_AT_language DW_LANG_C99 DW_AT_name tzb.c DW_AT_comp_dir /root DW_AT_low_pc 0x000106ac DW_AT_high_pc <offset-from-lowpc>188 DW_AT_stmt_list 0x00000000
Comment Actions Thank you very much for the investigation! The transition from riscv64-unknown-linux-gnu-gcc to gcc on qemu did improved. I can also set breakpoint on the designated memory address (failed to read the function names tho (main, etc)). Another issue I encountered (with this current patch, and same issue happened before) is that, if I kept executing "stepping" command, the ret (jalr) instruction cannot be executed properly and then the program entered into the illegal instruction region. Have you encountered the same issue by keeping stepping? Comment Actions address review comments
Comment Actions
I didn't run into the illegal instruction region, but I did find an infinity loop(about atomic lock), due to the lack of RVA extension. 110cc: 100427af lr.w a5,(s0) 110d0: 00079663 bnez a5,110dc <__run_exit_handlers+0x70> 110d4: 1ce426af sc.w.aq a3,a4,(s0) 110d8: fe069ae3 bnez a3,110cc <__run_exit_handlers+0x60> sc.w.aq is going to set a3 to zero, if it didn't succeed, the bnez a3,110cc will jump to 110cc, causing an infinity loop.
|
Upon this change, My lldb logging changes a bit. The instruction is not shown anymore, but stepping is still working. Is it as expected?