Re: [Qemu-stable] Call Trace for QEMU functions

[Michael Roth]

Quoting Naman patel (2015-07-30 05:21:39)
> Hi,
> 
>      I have compiled QEMU (2.0) for x86_64 on Fedora 22 with tracing enabled
> and the tracing option I chose was dtrace. I have this script called
> callTrace.stp in which I try and get the Call Trace of the function 
> helper_invlpg and later tlb_flush.  But I am not able to get the function name
> of the caller function and the call trace depth is only limited to 2.
> 
> probe process("/usr/bin/qemu-system-x86_64").function("helper_invlpg") {
>                 printf("gen_helper_invlpg called \n");
>                         print_usyms(ubacktrace())
> }
> 
> 
> I run it using following command: sudo stap -d /usr/local/bin/qemu
> -system-x86_64 --ldd --vp 08 callTrace.stp
> 
> Following is the ouput:
> gen_helper_invlpg called 
>  0x7faae9d7c040 : helper_invlpg+0x0/0x30 [/usr/bin/qemu-system-x86_64]
>  0x7faac5cfcd8c : 0x7faac5cfcd8c
> gen_helper_invlpg called 
>  0x7faae9d7c040 : helper_invlpg+0x0/0x30 [/usr/bin/qemu-system-x86_64]
>  0x7faac5cfcd8c : 0x7faac5cfcd8c
> gen_helper_invlpg called 
>  0x7faae9d7c040 : helper_invlpg+0x0/0x30 [/usr/bin/qemu-system-x86_64]
>  0x7faac5cfcd8c : 0x7faac5cfcd8c
> 
> and so on...
> 
> It does not show the function name but the address from where it was called.
> Does it mean that its not possible to get backtrace for this function???
> 
> Similarly if I probe for tlb_flush then I get the following output:
> TLB FULSH called 
>  0x7faae9cf19f0 : tlb_flush+0x0/0xb0 [/usr/bin/qemu-system-x86_64]
>  0x7faac6ab5722 : 0x7faac6ab5722
> TLB FULSH called 
>  0x7faae9cf19f0 : tlb_flush+0x0/0xb0 [/usr/bin/qemu-system-x86_64]
>  0x7faac6b689be : 0x7faac6b689be
> TLB FULSH called 
>  0x7faae9cf19f0 : tlb_flush+0x0/0xb0 [/usr/bin/qemu-system-x86_64]
>  0x7faac6a74998 : 0x7faac6a74998
> TLB FULSH called 
>  0x7faae9cf19f0 : tlb_flush+0x0/0xb0 [/usr/bin/qemu-system-x86_64]
>  0x7faac6b689be : 0x7faac6b689be
> 
> Here also I am not able to get full Call Trace.
> 
> If I do this similar kind of probe using stap -d /bin/ls --ldd -e 'probe
> process("ls").function("xmalloc") {print_usyms(ubacktrace())}' -c "ls /"
> then I do get proper call trace, Check the following output.
> 0x4112f0 : xmalloc+0x0/0x20 [/usr/bin/ls]
>  0x4114c4 : xmemdup+0x14/0x30 [/usr/bin/ls]
>  0x40eb4a : clone_quoting_options+0x2a/0x40 [/usr/bin/ls]
>  0x4033e2 : main+0xa52/0x2160 [/usr/bin/ls]
>  0x7fc6be4fc790 : __libc_start_main+0xf0/0x1d0 [/usr/lib64/libc-2.21.so]
>  0x404b19 : _start+0x29/0x30 [/usr/bin/ls]
>  0x4112f0 : xmalloc+0x0/0x20 [/usr/bin/ls]
>  0x4114c4 : xmemdup+0x14/0x30 [/usr/bin/ls]
>  0x40eb4a : clone_quoting_options+0x2a/0x40 [/usr/bin/ls]
>  0x403441 : main+0xab1/0x2160 [/usr/bin/ls]
>  0x7fc6be4fc790 : __libc_start_main+0xf0/0x1d0 [/usr/lib64/libc-2.21.so]
>  0x404b19 : _start+0x29/0x30 [/usr/bin/ls]
>  0x4112f0 : xmalloc+0x0/0x20 [/usr/bin/ls]
>  0x40378f : main+0xdff/0x2160 [/usr/bin/ls]
>  0x7fc6be4fc790 : __libc_start_main+0xf0/0x1d0 [/usr/lib64/libc-2.21.so]
> 
> Do you have any clue why this could happen? Or any alternative approach to get
> the call trace?
> 
> This is my first email on the group so please pardon me if I have not followed
> some customs.

I'd recommend re-sending this to address@hidden This list is
mainly for tracking patches/bugs relating to the maintenance of past
QEMU releases, whereas this email seems more like a general query.

In either case, address@hidden should always be CC'd regardless
of what specific address@hidden you send to. This allows the entire
community to help and stay in touch with what's going on in all areas.

> 
> Regards,
> Naman