Re: Running OProfile on Linux target running WR 2.6.36

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On 03/07/2012 06:12 AM, vis...@wi... wrote:
> Hello Mike,
> 
>  
> 
> Thanks for your help. Now we have flashed our oprofile enabled kernel and are able to use all the utilities of oprofile.
> 
>  
> 
> However, we noticed some behavior:
> 
> 1.    When we flashed our stripped non-debug application (with –Os flag), we could not see the details of our application in opreport.
> 
> 2.    So we built a debug application with –O0 –g flag. Now we are able to see the profiling info with the function names.
> 
>  
> 
> *Question 1:*Do we really need a debug build to get the profiling info?
If you're running opreport with "--debug-info", then you need to make the debuginfo versions of pertinent binaries available somehow.  I presume you're using oparchive on the target and running oprofile post-processing tools (e.g., opreport) on your host.  If not, you probably will want to do that.  On the host, you can create *.debug versions of the files with objcopy.  By default, opreport will look in the gnu_debuglink section of the runtime binary to get the basename of the debuginfo file, then it tries to find that file in the following locations:

	<filedir>/.debug/<basename>
	/usr/lib/debug/<filedir>/<basename>
	<filedir>/<basename>

where "<filedir>" is the directory where the runtime binary was located at profile time.

> 
> *Question 2:*We are not getting the call-graphs. It stops at very first level even though we specify –-call-graph=20. How do we get more info?
Adding Will Deacon to cc since call-graph support is arch-specific kernel stuff.  Hopefully, he can help answer this question.
> 
> *Question 3:*We are getting report in,
> 
> Sample % Linenr Symbol
> 
> We are interested in millisecond info i.e. how much time is spent in each function.
You'd have to do this kind of conversion by hand. Assuming you're using a free-running cycles type of event to profile on, you can come pretty close to calculating time spent per function.  But be aware, that oprofile does *not* record any information for processes that waiting for I/O.
> 
>  
> 
> Any documentation that points to this info or mail help would be greatly appreciated.
The oprofile user guide (http://oprofile.sourceforge.net/doc/index.html) has lots of good info.

-Maynard
> 
>  
> 
> Thanks,
> 
> Vish.
> 
>  
> 
>  
> 
> *From:*Michael Cashwell [mailto:mb...@pr...]
> *Sent:* Friday, February 24, 2012 8:41 PM
> *To:* Vishwanath Kulkarni (WT01 - Manufacturing & Hi Tech)
> *Cc:* opr...@li...
> *Subject:* Re: Running OProfile on Linux target running WR 2.6.36
> 
>  
> 
> On Feb 24, 2012, at 9:26 AM, <vis...@wi... <mailto:vis...@wi...>> wrote:
> 
> 
> 
> Hello Mike,
> 
>  
> 
> Thank you very much for the inputs you provided.
> 
>  
> 
> However, we are again unfortunate to get oprofile working. Here is what we did –
> 
>  
> 
> We have cross-compiled *oprofile.ko* and the kernel and got the *zImage* by following the steps that you gave. The following options we enabled in *.config* file and built the kernel,
> 
>  
> 
> CONFIG_PROFILING=y
> CONFIG_OPROFILE=m
> CONFIG_HAVE_OPROFILE=y
> 
>  
> 
> When we run oprofile on the target,
> 
> # opcontrol --init
> modprobe: can't load module oprofile (kernel/drivers/oprofile.ko): unknown symbol in module, or unknown parameter
> modprobe: can't load module oprofile (kernel/drivers/oprofile.ko): unknown symbol in module, or unknown parameter
> Kernel doesn't support oprofile
> 
>  
> 
> # lsmod
>     Tainted: P
> CDBlkDrv 40434 5 - Live 0x7f035000
> sd8xxx 37798 1 - Live 0x7f025000
> mlan 65945 1 sd8xxx, Live 0x7f00e000 (P)
> mrvlsdio 4334 1 sd8xxx, Live 0x7f007000
> 
>     This time we got one entry as “*Tainted: P*”. Not sure what this means though.
> 
>  
> 
> It related to whether or not all the source running in a Linux kernel is open or not. As you see above, your mlan module has a (P) [meaning proprietary]. That "taints" the running kernel and it limits the support you get from the community because they don't want to spend time debugging something that's running code whose source they cannot inspect.
> 
>  
> 
> In this case I don't think it relates to your problems.
> 
>  
> 
>     We even tried reading back the */proc/config.gz* to check for the options that we had set. Unfortunately they (CONFIG_OPROFILE, CONFIG_PROFILING) are not present in this file. Alternatively, when we executed “*uname –a*” on the target, the timestamp was not today’s date but rather the old kernel build date.
> 
>      
> 
>     Are we missing anything here?
> 
>  
> 
> Ah ok, you are seeing the problem. You said you built the kernel. The problem is you are not running that kernel. The oprofile module needs to be loaded into the kernel built and configured for it.
> 
>  
> 
> So we need to understand how your board is booting its kernel. What bootloader is in use? Does it boot from a network or from FLASH?
> 
>  
> 
> Somehow we need to preserve the kernel you have now (for safety's sake) and get the zImage (or some wrapped/compress version of it [again this depends on what boot loader you are using]) into the board so it is the kernel being used.
> 
>  
> 
> Then I expect your module will load.
> 
>  
> 
> Best regards,
> 
> -Mike
> 
> 
> 
>  
> 
> *From:* Michael Cashwell [mailto:mb...@pr...] 
> *Sent:* Thursday, February 23, 2012 7:59 PM
> *To:* Vishwanath Kulkarni (WT01 - Manufacturing & Hi Tech)
> *Cc:* opr...@li... <mailto:opr...@li...>
> *Subject:* Re: Running OProfile on Linux target running WR 2.6.36
> 
>  
> 
> Greetings,
> 
>  
> 
> On your target, do you have "/lib/modules/2.6.36/kernel/arch/arm/oprofile/oprofile.ko"? If so but modprobe can't find it then it sounds like some mismatch with modules.dep. I'm not sure how to help there except to maybe rebuild your kernel from scratch.
> 
>  
> 
> If you don't have that .ko file then you need to build it.
> 
>  
> 
> So in addition to CONFIG_HAVE_OPROFILE=y that you already have, you also need CONFIG_OPROFILE=m
> 
>  
> 
> Then in the top-level of the kernel tree and with:
> 
>  
> 
> # KARGS="ARCH=arm CROSS_COMPILE=<your tool chain>"
> 
> # KINSTDIR="<your build-time path to your staged root target file system>"
> 
>  
> 
> do something like:
> 
>  
> 
> # make $KARGS modules || abort "In-tree module build failed."
> 
> # make $KARGS INSTALL_MOD_PATH=$KINSTDIR modules_install || abort "In-tree module install failed."
> 
>  
> 
> That should provide the needed oprofile.ko in the place where modprobe (used by opcontrol) expects it.
> 
>  
> 
> (One note: we do build our own kernel zImage and we do it before the make steps above. That may be required. I'm not sure. If module building fails you might need to build your zImage first.)
> 
>  
> 
> Good luck!
> 
> -Mike
> 
>  
> 
> On Feb 23, 2012, at 8:43 AM, <vis...@wi... <mailto:vis...@wi...>> wrote:
> 
> 
> 
> 
> Hello,
> 
>  
> 
> We are having a target device that runs *WR Linux* with kernel *2.6.36* on *ARMv7* based processor.
> 
>  
> 
> We have cross-compiled *OProfile* with following options,
> 
> *./configure --host=arm-linux CC=<our tool chain>gcc CXX=... ...etc...*
> 
>  
> 
> When running *./configure* we observed the statement something like *"Checking kernel support for OProfile ... yes"*
> 
>  
> 
> *_The product of this build are:_*
> 
> libbfd-2.22.so             libbfd.so          libpopt.so.0    libpopt.so.0.0.0        opannotate
> 
> oparchive                   opcontrol         opgprof          ophelp                       opjitconv
> 
> opreport                    oprofiled
> 
>  
> 
> *_On target board:_*
> 
> # cat /proc/modules
> 
> CDBlkDrv 40434 5 - Live 0x7f035000
> 
> sd8xxx 37798 1 - Live 0x7f025000
> 
> mlan 65945 1 sd8xxx, Live 0x7f00e000 (P)
> 
> mrvlsdio 4334 1 sd8xxx, Live 0x7f000000
> 
>  
> 
> *_When we run "opcontrol --init" on the target board, we get the following error:_*
> 
> # opcontrol --init
> 
> modprobe: module oprofile not found in modules.dep
> 
> modprobe: module oprofile not found in modules.dep
> 
> Kernel doesn't support oprofile
> 
>  
> 
> How do we make this "*opcontrol*" run successfully on the target board? The kernel is already built with *CONFIG_HAVE_OPROFILE=y* option. This we confirmed by seeing the option in the file */proc/config.gz* on the target board. Do we still need to build *oprofile.ko*
> 
>  
> 
> If yes, how do we do.
> 
> If not, then how do we get away with this problem.
> 
>  
> 
> Any help in this regard is appreciated.
> 
>  
> 
> Thanks and Regards,
> 
> Vish.
> 
>  
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/_______________________________________________
> oprofile-list mailing list
> opr...@li... <mailto:opr...@li...>
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
> 
>  
> 
>  
> 
> 
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> 
> 
> 
> _______________________________________________
> oprofile-list mailing list
> opr...@li...
> https://lists.sourceforge.net/lists/listinfo/oprofile-list