[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-discuss] Question regarding tracing guest execution using qemu-sys

From: Ronald De Keulenaer
Subject: [Qemu-discuss] Question regarding tracing guest execution using qemu-system-sparc
Date: Fri, 2 Jun 2017 13:55:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

Dear Qemu developer community members,

I was wondering if any of you have any experience with using Qemu for tracing execution of guest instructions under full system emulation. Specifically, I am trying to obtain an execution trace using qemu-system-sparc.

My source code has been patched to create LEON3-compatible binaries (kernels), but the following patch illustrates my modifications against unaltered Qemu 2.9.0 source code:

diff -urN a/target/sparc/translate.c b/target/sparc/translate.c
--- a/target/sparc/translate.c    2017-04-20 16:57:01.000000000 +0200
+++ b/target/sparc/translate.c    2017-05-31 16:49:09.621150561 +0200
@@ -3175,6 +3175,9 @@
     TCGv_i64 cpu_src1_64, cpu_src2_64, cpu_dst_64;
     target_long simm;

+    printf("{__trace.ins @ (0x)%08x}\n", dc->pc);
+    fflush(stdout);
     opc = GET_FIELD(insn, 0, 1);
     rd = GET_FIELD(insn, 2, 6);

This initially seemed to output correct control flow for very simple programs, but I soon noticed that traces were incomplete (e.g. an instruction at address X seems to be executed far less than normal) and incorrect (e.g. control flow seems to skip over some function calls completely). I realize an example binary would come in handy in case anyone would want to reproduce what I'm observing, but, like I said, in reality I patched a significantly older version of Qemu to generate LEON3-compatible binaries. Providing all of the patches I used, as well as the customly crafted binary I'm running, seems unnecessary to me. Furthermore, it would become circuitous to explain my problem.

I suspect that I'm intercepting the value of the program counter at a location that's just wrong. Can anyone tell me how I can correctly instrument Qemu to get the trace I want?

If memory serves correctly, a simple modification very similar to the one described above served me just fine when modifying qemu-user-arm in the past. I realize that's beside the point, but it's the reason I attempted the same approach now.

Note that I am aware of existing tracing functionality within Qemu! I have tried enabling the simple tracing backend by running ./configure with --trace-backend=simple, as per the documentation in /docs/tracing.txt, but I can't seem to find any events that report the PC, or anything I can use, in resulting trace files. For sure, if I can use the simple tracing backend to achieve the desired result, that's an equally good solution. I just want a trace that's correct.

Thanks in advance for any and all help.

Best regards,

Ronald De Keulenaer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]