lmi
[Top][All Lists]
Advanced

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

Re: [lmi] perf+wine


From: Vadim Zeitlin
Subject: Re: [lmi] perf+wine
Date: Tue, 6 Mar 2018 20:59:11 +0100

On Fri, 2 Mar 2018 11:30:55 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-02-28 13:15, Vadim Zeitlin wrote:
GC> [...]
GC> >  Also, running perf under Linux is always worthwhile -- and very simple to
GC> > do, so I'd also do this and see if you notice anything unusual in its
GC> > output. You could run just the Wine process itself under it or even run it
GC> > system-wide, if your system is reasonably idle, Wine should dominate all
GC> > the statistics anyhow.
GC> $perf record wine ./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data
GC> 
GC> $perf report
GC> Samples: 350K of event 'cycles', Event count (approx.): 260014842317
GC> Overhead  Command        Shared Object      Symbol
GC>   66.60%  lmi_wx_shared  [unknown]          [.] 0x000000007bc50843
GC>    1.04%  lmi_wx_shared  [unknown]          [.] 0x000000007bc50830
GC>    0.69%  lmi_wx_shared  [unknown]          [.] 0x000000007bc3d88c
GC>    0.67%  lmi_wx_shared  perf-19333.map     [.] 0x000000006d0d38dc
GC>    0.65%  lmi_wx_shared  [unknown]          [.] 0x000000007bc3d744

 Unfortunately I failed to understand how does this work. It looks like
there is some support for Wine in perf -- or for perf in Wine -- because
something creates the temporary .map files above which are supposed to
allow getting symbols for code without them (e.g. this is how perf can be
used with Java), but I can't find where does the magic happen nor where are
the symbols actually supposed to come from... I do feel rather stupid, but
after spending too much time on this already, I'm afraid I have to abandon
this.

GC> /opt/lmi/bin[0]$addr2line -e ./lmi_wx_shared.exe 0x000000007bc50843
GC> ??:0
GC> /opt/lmi/bin[0]$i686-w64-mingw32-addr2line -e ./lmi_wx_shared.exe 
0x000000007bc50843 
GC> ??:0

 But both of these commands do work fine for me (I was surprised that the
former one did, to be honest, but binutils is smarter than I thought). I
use the binary built using the autoconf-based system, however, which uses
plain "-g", while the official makefiles use "-ggdb", I wonder if this
could explain the problem somehow?


GC> This command:
GC>   $i686-w64-mingw32-nm ./lmi_wx_shared.exe 2>&1 |less
GC> shows symbols in the general range of 00400000, e.g.:
GC>   004014c0 T _WinMainCRTStartup
GC>   0040635c I __nm___ZN16wxAppConsoleBase12ms_appInitFnE

 This is a strange symbol name, what does this "__nm__" prefix mean?
Without it, this would be "wxAppConsoleBase::ms_appInitFn", but with it
neither c++filt nor i686-w64-mingw32-c++filt can demangle it.

GC> Is there a simple magical incantation that translates
GC>     66.60%  lmi_wx_shared  [unknown]          [.] 0x000000007bc50843
GC> to a symbol name?

 I don't have anything magical, but both addr2line and, perhaps more
usefully, i686-w64-mingw32-gdb (in combination with gdbserver running under
Wine) work just fine for me and both show the correct symbols.

 But there is still the problem with perf not seeing them and not seeing
the caller graph neither, presumably because of this. This alone makes it
not very useful for debugging programs running under Wine, which is very
unfortunate as it's a great tool. But, if you think it's worth spending
more time on this at all, I probably need to ask for help somewhere because
I just can't find anything on my own, unfortunately.

 Regards,
VZ


reply via email to

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