similar to: how will CentOS handle the perftools 1.7 vs. 1.6 issue?

I have this problem: google-perftools fails to detect stack for the code run under JIT called through C++ api from my program. It shows in profile like all program is one block with the name _init. I clearly do set the option NoFramePointerElim and I do see how it makes a difference in stack frame under gdb. When running some code in JIT in lli (with option -disable-fp-elim) google perftools

I am trying to run some code allocating a lot of memory and not releasing it in JIT under google-perftools. Just one function 'main' calling 'malloc'. google-perftools fails to correctly read stack when malloc is called from inside the JITted code, and as a result perftools report is wrong: address of 'main' procedure appears shifted 0x3946e1d0->0x3946e1ed and is

This new option will allow to output function information in the same format as addr2line from binutils emits: ... 0xABCDEF01 T function_name_is_here ... This feature is useful to profile the code when it is run in JIT by external tools like valgrind and google-perftools. For example, google-perftools runs addr2line on executable and uses the resulting file to resolve memory addresses to

This new option (--jit-emit-debug-function-range) will allow to output function information for memory ranges that functions occupy in memory while they run in JIT. File format generated is like this: ... 0x5000000 0x5001000 function_name_is_here ... This feature is useful for external tools like valgrind and google-perftools to profile the code when it is run in JIT. Particularly

Have you found http://llvm.org/docs/DebuggingJITedCode.html? The JIT already has support for something like this for gdb's benefit. Perftools and valgrind just don't know how to find it yet. On Sat, Jun 19, 2010 at 2:03 PM, Yuri <yuri at rawbw.com> wrote: > This new option (--jit-emit-debug-function-range) will allow to output > function information for memory ranges that

Hi, This is a proposed fix for bug 16847 [1]. It is essentially the patch provided by Martin Nowack in the bug report but I have added a test case and an ifdef macro around the modified code in Process::GetMallocUsage() The issue seems to be that the ptmalloc2 allocator used in glibc (in my case 2.19) does not include mmap()'ed memory in mallinfo.uordblks and so mallinfo.hblkhd needs to be

On Jun 18, 2010, at 3:29 AM, Yuri wrote: > Now I see that JITted code doesn't have standard prolog, on x86 each > procedure instead begins with 'sub $0x4,%esp'. > > Is there an option to make JIT generate regular prologs? Try turning off frame pointer elimination. On the llc command line, this is -disable-fp-elim -Chris > > Yuri >

On Sat, Jun 19, 2010 at 4:35 AM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 18, 2010, at 3:29 AM, Yuri wrote: > >> Now I see that JITted code doesn't have standard prolog, on x86 each >> procedure instead begins with 'sub    $0x4,%esp'. >> >> Is there an option to make JIT generate regular prologs? > > Try turning off frame

On 06/19/2010 14:14, Jeffrey Yasskin wrote: > Have you found http://llvm.org/docs/DebuggingJITedCode.html? The JIT > already has support for something like this for gdb's benefit Yes, I saw it and tried it. -jit-emit-debug generates ELF image in memory with debug info. Another option -jit-emit-debug-to-disk creates .o ELF files with debug info, one per function. If there are thousands

On 06/19/2010 14:03, Yuri wrote: > This new option (--jit-emit-debug-function-range) will allow to output > function information for memory ranges that functions occupy in memory > while they run in JIT. File format generated is like this: > ... > 0x5000000 0x5001000 function_name_is_here > ... > > This feature is useful for external tools like valgrind and >

On Thu, Feb 10, 2011 at 11:31 AM, Kai Schaetzl <maillists at conactive.com> wrote: > > This wasn't the first instance. This guy has recently started a habit of > copying mails (that are not his own it seems) that trip him off right to > this list. That is bad practice. I do not want to get more of this. > > Kai Kai, as you may not already know, Will Rogers said

Is anybody using the google heap profiler to analyze clang/llvm ?? http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html If so, do you know how to modify the build scripts to enable that. Tia. Reed

On 11/11/2011 11:39 AM, Chandler Carruth wrote: > On Fri, Nov 11, 2011 at 11:36 AM, reed kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > > Is anybody using the google heap profiler to analyze clang/llvm ?? > > http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html > > If so, do you know how to modify the build

This may or may not be of interest to CentOS developers; if it is not or if it is redundant of your efforts to keep atop of what's happening, you have my apologies. Whether it is joint or disjoint wrt to the upstream code is not known at this point, but I have submitted a request for elucidation if CERN security allows. kind regards/ldv ---------- Forwarded message ---------- From: Ewan

Hi, I want to measure the performance of functions within a program, in order to see whether or not a given set of optimizations are useful (making the code faster in my case). It would be ideal to compare the LLVM IR representation of the functions before and after the optimizations, but the process has to be automatized so if there is no code that can do this now then I guess it will be too

On Fri, Nov 11, 2011 at 11:36 AM, reed kotler <rkotler at mips.com> wrote: > Is anybody using the google heap profiler to analyze clang/llvm ?? > > http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html > > If so, do you know how to modify the build scripts to enable that. > > Tia. I have tried to use this in the past without terribly much success.

Olly Betts <olly at survex.com> wrote: > The report you show seems to be just the time take by each function > directly rather than including functions it calls. It looks like a lot > of the time is spent in cursor movement, as totalling up things that > seem like they'd be due to that I quickly get to 40+% but it's hard > to tell if that's about the actual total

Now I see that JITted code doesn't have standard prolog, on x86 each procedure instead begins with 'sub $0x4,%esp'. Is there an option to make JIT generate regular prologs? Yuri

On Fri, Nov 11, 2011 at 11:45 AM, reed kotler <rkotler at mips.com> wrote: > ** > On 11/11/2011 11:39 AM, Chandler Carruth wrote: > > On Fri, Nov 11, 2011 at 11:36 AM, reed kotler <rkotler at mips.com> wrote: > >> Is anybody using the google heap profiler to analyze clang/llvm ?? >> >>

I'm asking here, rather than R-devel, because it seems to be a Linux specific question and because I'm using Ubuntu-9.04. I'm trying to profile an package, and got errors, so I decided to follow BDR's (http://tolstoy.newcastle.edu.au/R/devel/06/02/4254.html) example exactly, and got same problem. Can anyone replicate? $ sudo mkdir -p /var/tmp//usr/lib/R/library/stats/libs $