<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
If that works when you test it, could you send a patch to commits
list?<br>
<br>
Philip<br>
<br>
<div class="moz-cite-prefix">On 11/29/2014 09:41 AM, Maurice Marks
wrote:<br>
</div>
<blockquote
cite="mid:CAOZ=Yo1dbhBAwcXziYiKme_ibtHik6hM_=YsBW2WJ6enJd_2Og@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Lang. Thanks for that tip! That's a good idea/<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Nov 29, 2014 at 12:08 AM, Lang
Hames <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Mi Maurice,
<div><br>
</div>
<div>A follow up to Andy's comments: MCJIT can find line
numbers for ELF files, at least in limited
circumstances. I know because I broke the regression
test for it while doing some cleanup recently. ;)</div>
<div><br>
</div>
<div>Looking at
lib/ExecutionEngine/OProfileJIT/OProfileJITEventListener.cpp,
I see the line:</div>
<div><br>
</div>
<div>// TODO: support line number info (similar to
IntelJITEventListener.cpp) </div>
<div><br>
</div>
<div>From a glance at IntelJITEventListener, I think it
would be easy to copy the line number support in there
over to OProfileJITEventListener. </div>
<div><br>
</div>
<div>Cheers,</div>
<div>Lang.<br>
<div> </div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div class="h5">On Fri, Oct 17, 2014 at 3:04 PM,
Kaylor, Andrew <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:andrew.kaylor@intel.com"
target="_blank">andrew.kaylor@intel.com</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The
fact that you are getting line number
information leads me to believe that
whether you intended it or not you are
using the old JIT (which is now gone), not
MCJIT. The “Mapping 0x7f5ed6893032 to
loopy.c:13” lines come from a path called
through NotifyFunctionEmitted and as far
as I know nothing in MCJIT calls that.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">At
one time oprofile support worked
completely with the old JIT. It sounds
like you might have a build where the old
JIT was partially dismantled. That may or
may not be why things aren’t working for
you.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">With
MCJIT, I would expect that oprofile
support would work, minus line numbers.
I’m not sure about that though, as I
haven’t tried anything with oprofile and
MCJIT for a couple of years and the code
has changed a lot recently.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m
not sure this is relevant, but I seem to
recall having had to run oprofile for
system level profiling. Perhaps the
registration mechanism isn’t passing
through enough information to associate
the addresses it is registering with the
process you are profiling.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Incidentally,
it should be possible to get line number
support with oprofile and MCJIT. It just
isn’t implemented yet.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-Andy</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:llvmdev-bounces@cs.uiuc.edu"
target="_blank">llvmdev-bounces@cs.uiuc.edu</a>
[mailto:<a moz-do-not-send="true"
href="mailto:llvmdev-bounces@cs.uiuc.edu"
target="_blank">llvmdev-bounces@cs.uiuc.edu</a>]
<b>On Behalf Of </b>Maurice Marks<br>
<b>Sent:</b> Friday, October 17, 2014 8:37
AM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:llvmdev@cs.uiuc.edu"
target="_blank">llvmdev@cs.uiuc.edu</a><br>
<b>Subject:</b> [LLVMdev] oprofile
support?</span></p>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">I've
been trying to get oprofile
results for jitted code
without success. I built an
3.5.0 llvm with oprofile
enabled, and tested it with
lli on a small test case. I
built the latest oprofile from
the git repository.<br>
<br>
Debugging I can see that lli
is registering the listener
and making the oprofile calls
to the libopagent api to
specify the names and address
ranges of jit'd routines, and
even the line number
information. And the oprofile
agent is writing infomation to
/tmp/.oprofile/jitdump. But
although oprofile counts lots
of samples but doesnt
attribute them to the jit'd
code. When execution finishes
oprofile runs opjitconv to
report the jit counts but
doesn't see how to attribute
them so drops them on the
floor.<br>
Working with one of the
primary oprofile developers,
Maynard Johnson, we've got a
couple of theories:</p>
</div>
<p class="MsoNormal">1) oprofile
jit code support doesn't
actually work with MCJIT yet.
Although its supposed to work
there are no examples we could
find in recent web history. Does
anyone have a working example?</p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">2)
Using a small test case the jit'd
code is on a small region of heap
memory. Because it isnt marked as
anonymous (as it would be if it
came from an mmap/large malloc
request) oprofile ignores the
samples. I would have though it
would attribute those samples to
lli which owns its heap. Perhaps
that's a bug?
</p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">My test
case is this little C program
converted to IR and run with lli:</p>
</div>
<p class="MsoNormal">loopy.c:<br>
<br>
#include <stdio.h> <br>
int fib_left(int); <br>
int fib_right(int); <br>
int fib_left(int i) {<br>
if (i < 2) return 1; <br>
return fib_left(i-1) +
fib_right(i-2); } <br>
int fib_right(int i) { if (i < 2)
return 1; <br>
return fib_left(i-1) + fib_right(i-2);
} <br>
int fib(int i) { if (i < 2) return
1; <br>
return fib_left(i-1) + fib_right(i-2);
} <br>
<br>
int main() { <br>
int i = 45; printf("fib(%d) == %d\n",
i, fib(i)); }<br>
<br clear="all">
</p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">$clang
-g -S -emit-llvm -o
loopy.ll loopy.c<br>
<br>
$ operf -Vdebug -e
CPU_CLK_UNHALTED:5000000
lli
-debug-only="oprofile-jit-event-listener"
loopy.ll<br>
Using samples dir
/home/dad/oprofile_data/samples<br>
Kernel profiling is
not possible with
current system config<br>
Set
/proc/sys/kernel/kptr_restrict
to 0 to collect kernel
samples.<br>
Exec args are: lli
-debug-only=oprofile-jit-event-listener
loopy.ll <br>
telling child to start
app<br>
app 47033 is running<br>
parent says start app
/usr/local/bin/lli<br>
Forking read pid<br>
going into waitpid on
profiled app 47033<br>
Successfully read
header info for sample
data <br>
Converting operf data
to oprofile sample
data format<br>
sample type is 43<br>
operf: Profiler
started<br>
Connected to OProfile
agent. <<<
from the jit event
listener code<br>
Mapping 0x7f5ed6893014
to loopy.c:13
<<< adding
debug line information
in the listener<br>
Mapping 0x7f5ed689301f
to loopy.c:13<br>
Mapping 0x7f5ed6893032
to loopy.c:13<br>
Mapping 0x7f5ed6893054
to loopy.c:14<br>
Mapping 0x7f5ed6893079
to loopy.c:9<br>
Mapping 0x7f5ed6893082
to loopy.c:9<br>
Mapping 0x7f5ed689308e
to loopy.c:10<br>
Mapping 0x7f5ed68930a1
to loopy.c:10<br>
Mapping 0x7f5ed68930b8
to loopy.c:10<br>
Mapping 0x7f5ed68930d9
to loopy.c:5<br>
Mapping 0x7f5ed68930e2
to loopy.c:5<br>
Mapping 0x7f5ed68930ee
to loopy.c:6<br>
Mapping 0x7f5ed6893101
to loopy.c:6<br>
Mapping 0x7f5ed6893118
to loopy.c:6<br>
Mapping 0x7f5ed6893139
to loopy.c:7<br>
Mapping 0x7f5ed6893142
to loopy.c:7<br>
Mapping 0x7f5ed689314e
to loopy.c:8<br>
Mapping 0x7f5ed6893161
to loopy.c:8<br>
Mapping 0x7f5ed6893178
to loopy.c:8<br>
fib(45) == 1836311903<br>
profiled app ended
normally.<br>
operf recording
finished.<br>
Total bytes recorded
from perf events:
226136<br>
operf-record process
returned OK<br>
operf_read: Total
bytes received from
operf_record process:
225952<br>
Calling
_do_jitdump_convert
<<<<
oprofile converting
jit sample information<br>
start time/end time is
1413559198/1413559208<br>
opjitconv: Ending with
rc = 2. This code is
usually OK, but can be
useful for debugging
purposes.
<br>
JIT dump processing
complete.<br>
operf-read process
returned OK<br>
<br>
Profiling done.<br>
<br>
$ opreport<br>
Using
/home/dad/oprofile_data/samples/
for samples directory.<br>
CPU: Intel Haswell
microarchitecture,
speed 3498 MHz
(estimated)<br>
Counted
CPU_CLK_UNHALTED
events (Clock cycles
when not halted) with
a unit mask of 0x00
(No unit mask) count
5000000<br>
CPU_CLK_UNHALT...|<br>
samples| %|<br>
------------------<br>
6949 100.000 lli<br>
CPU_CLK_UNHALT...|<br>
samples| %|<br>
------------------<br>
6903 99.3380
<a
moz-do-not-send="true"
href="http://ld-2.19.so" target="_blank">ld-2.19.so</a><br>
23 0.3310
no-vmlinux<br>
10 0.1439
libLLVMCore.so<br>
8 0.1151
libLLVMCodeGen.so<br>
2 0.0288
<a
moz-do-not-send="true"
href="http://libpthread-2.19.so" target="_blank">libpthread-2.19.so</a><br>
1 0.0144
libLLVMAsmPrinter.so<br>
1 0.0144
libLLVMSelectionDAG.so<br>
1 0.0144
libLLVMTransformUtils.so<br>
<br>
$ opreport -l `which
lli`<br>
Using
/home/dad/oprofile_data/samples/
for samples directory.<br>
CPU: Intel Haswell
microarchitecture,
speed 3498 MHz
(estimated)<br>
Counted
CPU_CLK_UNHALTED
events (Clock cycles
when not halted) with
a unit mask of 0x00
(No unit mask) count
5000000<br>
samples %
image
name
symbol name<br>
38 57.5758
no-vmlinux
/no-vmlinux<br>
2 3.0303 <a
moz-do-not-send="true" href="http://ld-2.19.so" target="_blank">ld-2.19.so</a>
_dl_lookup_symbol_x<br>
2 3.0303
libLLVMCore.so
llvm::DenseMapBase<llvm::DenseMap<void
const*, llvm::PassInfo
const*,
llvm::DenseMapInfo<void
const*> >, void
const*, llvm::PassInfo
const*,
llvm::DenseMapInfo<void
const*>
>::getHashValue(void
const* const&)<br>
2 3.0303
libLLVMCore.so
std::vector<llvm::PassInfo
const*,
std::allocator<llvm::PassInfo
const*>
>::begin() const<br>
1 1.5152 <a
moz-do-not-send="true" href="http://ld-2.19.so" target="_blank">ld-2.19.so</a>
_dl_check_map_versions<br>
1 1.5152 <a
moz-do-not-send="true" href="http://ld-2.19.so" target="_blank">ld-2.19.so</a>
_dl_fixup<br>
1 1.5152 <a
moz-do-not-send="true" href="http://ld-2.19.so" target="_blank">ld-2.19.so</a>
do_lookup_x<br>
1 1.5152
libLLVMAsmParser.so
llvm::LLLexer::ReadString(llvm::lltok::Kind)<br>
1 1.5152
libLLVMCodeGen.so
llvm::MachineFunction::getName()
const<br>
1 1.5152
libLLVMCodeGen.so
llvm::MachineOperand::isReg()
const<br>
....</p>
</div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">From
this you can see that
lli is calling the
oprofile interface.
Oprofile is counting
6949 samples, but
attributing 99% to
<a
moz-do-not-send="true"
href="http://ld-2.19.so" target="_blank">ld-2.19.so</a>. They are
actually the samples
from the jit code
execution.</p>
</div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">Asking
opreport to show the
samples from lli it
only sees the jit
compilation samples
(<1% of the total).
Asking for the samples
from
<a
moz-do-not-send="true"
href="http://ld-2.19.so" target="_blank">ld-2.19.so</a> shows the same
info - just the
compilation process.</p>
</div>
<div>
<p class="MsoNormal">Perhaps
I'm missing something
obvious so I wanted to
ask the list if there
was anyone actively
using oprofile with
jit'd code so we can
resolve the problem.<br>
<br>
thanks!</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<span class="">_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</span></blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="gmail_signature">
<div dir="ltr">Not sent from my Blackberry, Raspberry or
Gooseberry!</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</body>
</html>