CC'ed to the list. > > > Am I misunderstanding something? How exactly this reallocation happens > > (or > > > where in the source code am I able to track and understand the process)? > > > > http://lugatgt.org/content/qemu_internals/downloads/slides.pdf > > > > http://m1.archiveorange.com/m/att/1XS1v/ArchiveOrange_YD2LcLkRqU2so0i2Zoj99h2bwUsa.pdf > > > > Should be good start. > > > > This was very insightful. Which is the book that contains the mentioned > chapter? I would like to read it completely.
I don't know the book, but I think this chapter is good enough. :) > > > Second, what exactly means the identifying letters of arguments counted > > in > > > front of each instruction (i, o, c) ? Is it too hard to create a patch on > > > the disassembly function to also output its values? > > > > Sorry, I don't understand what you're trying to do. Where do you see > > those > > identifying letters? > > > > It is on the output generated with -d out_asm option. One example: > > 0x6023d908: call o=0 i=1 c=2 From the what you say below, I guess your're using TCI not TCG, right? > Okey. I'm familiar with objdump, but I couldn't generate a similar output > with qemu. All I could get was the IR with code cache addresses, and not a > dump with the translated asm or even the IR with original addresses (like > you mentioned above, also highlighting the function names). Is it possible > for me to do? Try to use TCG? :) > Here is an example of what I'm trying to do: > > I'm trying to trace a process execution inside qemu and map every call > instruction executed, being able to identify where this call led the > execution flow. So far, I've been able to generate the out_asm output > (which is built-in) and I also have modified the interpreter code to output > the addresses of the instruction executed. Following the instructions > executed I noticed that the calls are not modifying the code flow, as > follows: > > Example out_asm code block: > 0x6023d908: call o=0 i=1 c=2 > 0x6023d913: ext32u_i64 o=1 i=1 c=0 > 0x6023d917: shr_i64 o=1 i=2 c=0 > 0x6023d924: or_i64 o=1 i=2 c=0 > > Example output generated by the tracer I inserted in tci: > CALL executed: 6023d908 > Instruction executed: 6023d913 > Instruction executed: 6023d917 > Instruction executed: 6023d924 I *guess*, for example, the call is to call some helper functions which are normal C functions (target-i386/op_helper.c). What you record is only the execution flow in the code cache. > As we see, the call didn't redirect the code (and it happens always with > other calls in the code). I imagine that it is an optimization that places > subsequent code on the code cache, to avoid the need to jump to somewhere > else (so the call destination needs to be eagerly decided). > > So, how wrong am I about it? Is there some explanation I need to get or > some source code I should read in order to understand better what is > happening here? See above. > Finally, as I am trying to trace the functions called, is it possible for > me to output the true address of the translated instruction instead of its > code cache address? If yes, this would allow me to compare the generated > trace and with the dump of the IR, making it easy to draw a code flow graph. I think you need to output the guest pc, which is ususally something like "target_ulong pc". Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
