qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Doubts about qemu tcg/tci


From: 陳韋任
Subject: Re: [Qemu-devel] Doubts about qemu tcg/tci
Date: Wed, 14 Mar 2012 11:04:23 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

  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



reply via email to

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