Hello,
I’m new for spike and RISC V.
I’m trying to do some dymic instruction trace with spike.These instructions are from a sample.c file. I have tried the following command:
riscv64-unknown-elf-gcc simple.c -g -o simple.out
riscv64-unknown-elf-objdump -d --line-numbers -S simple.out
But these commands display the assembled instructions in an out file, which is not I want. I need to trace the dynamic executed instruction in runtime. I find only two relative commands in spike host option:
-g : track histogram of PCs
-l : generate a log of execution
I’m not sure if the result is what I expected as above.
Does anyone have a idea how to do the dynamic instruction trace in spike?
Thanks a lot!
The spike -l option should give you the result you want.
Spike is a system simulator for running operating systems. It can’t run user code directly. But there is a program called pk in the risck-pk package that can let you run user programs on spike. However, with the -l option, you will get a trace that contains both pk instructions and your user program instructions, so you may need to process that to get the info you want.
There is another option, the gdb simulator. This is riscv64-unknown-elf-run. Add the --help option to see what the options are. This can run user prorgams directly, and the --trace-insn option will produce an instruction trace.
1 Like
Thanks a lot!
Your answer is very helpful. I’ve tried these two methods that you mentioned. However, I still have one question about spike -l option:
I am interested in the trace from -l option, which contains both pk instructions and user programs instructions. Are these two kinds of instructions mixed up with each other? Or they have obvious boundaries so that we can separate one from another? Is there any good way to process the trace?
I need to trace the dynamic runtime instructions to detect whether exists runtime attack in user program.
Thanks once more!
The program will start in pk, because it is the “OS” that runs on spike, and then eventually pk will call _start in your program, then when the program makes syscalls vis scall you return to pk for the syscall which will do an sret when it is done. So you can look for the scall and sret instructions, and the address of _start. That should get you just the application instructions from the trace.
1 Like
Thanks for your answer. That is exactly what I need! But I still have some questions about the trace instructions. I did see “ecall” and “sret” in the trace and I found the corresponding relation between them. However, there are also some “sret” corresponding to “exception trap_instruction_page_fault, …”. Are those instructions between them also the instructions executed in the pk?
Yes, that would also be pk code for handling page faults.
1 Like