[Qemu-devel] Doubts about qemu tcg/tci

[Qemu-devel] Doubts about qemu tcg/tci

[João Corrêa]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

Hi,

Hopefully I'm sending this e-mail to the right list. If not, please ignore
it!

I'm trying to read the asm code generated with the -D qemu option, but I am
having some difficulties.

First, I've seen that the generated asm is allocated in different address
ranges. The beginning of the dump says:

end_code    0x080486dc
start_code  0x08048000

but the first instruction's address is: 0x6022caf0

Am I misunderstanding something? How exactly this reallocation happens (or
where in the source code am I able to track and understand the process)?

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?

Third, Is there a trivial way for me to track an original function inside
the generated asm dump? I mean, if I create a C function called foo(), that
is called somewhere inside the main function, what should I do in order to
find the translated instructions inside the outputted dump?

Finally, I've been trying to find material about how this translation works
properly, but I've been unable to find much. Is there something I should be
reading before asking around here? If yes, please, point me to it!

Thank you for your time. Any help with any question will be very useful to
me.

[-- Attachment #2: Type: text/html, Size: 1790 bytes --]

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

[陳韋任]

> I'm trying to read the asm code generated with the -D qemu option, but I am
> having some difficulties.

  Should be "-d" option.
 
> First, I've seen that the generated asm is allocated in different address
> ranges. The beginning of the dump says:
> 
> end_code    0x080486dc
> start_code  0x08048000

  This is guest binary range.
 
> but the first instruction's address is: 0x6022caf0

  This is the address of host binary in the code cache.
 
> 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.
 
> 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?
 
> Third, Is there a trivial way for me to track an original function inside
> the generated asm dump? I mean, if I create a C function called foo(), that
> is called somewhere inside the main function, what should I do in order to
> find the translated instructions inside the outputted dump?

  `objdump -D` should show you the address of the function you're interested in.
For example, function foo() locates 0x080483b4. You can lookup qemu.log for that
address. Also, it seems QEMU will log the function name, too. Say,

----------------
IN: foo          <---
0x080483b4:  push   %ebp
0x080483b5:  mov    %esp,%ebp
0x080483b7:  pop    %ebp
0x080483b8:  ret
 
 
> Finally, I've been trying to find material about how this translation works
> properly, but I've been unable to find much. Is there something I should be
> reading before asking around here? If yes, please, point me to it!

  See above.

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

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

[陳韋任]

  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