OProfile

Hello,

 

I am try to use OProfile on embedded system boards. I want collect data on
the target board and produce summaries on my host. My question is that do I
need to prepare non-stripped images both on the target board and my host OR
just on my host. Thanks a lot for any reply.

 

BR,

HW

Re: non-stripped file for symbol-based profiling From: Maynard Johnson <maynardj@us...> - 2011-08-15 17:13 hwyang wrote: > Hello, > > > > I am try to use OProfile on embedded system boards. I want collect data on > the target board and produce summaries on my host. My question is that do I > need to prepare non-stripped images both on the target board and my host OR > just on my host. Thanks a lot for any reply. It would have been nice if someone from the oprofile community with embedded experience had replied to you, but since that doesn't seem to be happening, I'll give you some advice. Yes, you can run stripped binaries on your target. After running the profile session, use oparchive to package up all the binaries and sample data needed for post-processing on your host system. After extracting the data on your host system, run opreport something like the following: 'opreport --symbols archive:<path-to-oparchive-extract-dir>' Now, with a stripped binary, your symbols report won't actually show symbols without some extra steps. There are different ways you can provide the debuginfo that opreport needs. You can use the brute force method and simply replace the stripped binary in question (found within the path-to-oparchive-extract-dir on your host system) with a non-stripped binary. One minor downside to that is opreport is going to complain that this binary doesn't seem to be the one used when the profile was taken. The preferred method (in my mind) is to use objcopy: 1) Use '--only-keep-debug' to create a <binary-name>.debug file; 2) use '--strip-all' to strip your runtime binary; and 3) use '--add-gnu-debuglink' to add a link in your runtime binary to the <binary-name>.debug file. Then, after collecting the profile and using oparchive, extract the archive on your host system and copy the *.debug file(s) to a location where oprofile can find it(them). The location can either be the same di rectory as the runtime binary (again, within the path-to-oparchive-extract-dir on your host system) or you can create a debuginfo directory within the path-to-oparchive-extract-dir and pass that fully-qualified path (minus the top-level archive extraction destination directory) to opreport using the '--image-path' option. Example: You use the above objcopy steps to create a foo.debug file for a stripped runtime binary 'foo'. On the target system, 'foo' is placed in /apps/tests. After running oprofile on the target system, you run oparchive to create an archived directory. You tar up that directory and extract the tar file to /my/home/arch1 on your host system. Then create a /my/home/arch1/apps/debuginfo directory and place your foo.debug files there. You would run opreport as follows: 'opreport --symbols archive:/my/home/arch1 --image-path=/apps/debuginfo ./apps/test/foo' -Maynard > > > > BR, > > HW > > > > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. > http://p.sf.net/sfu/wandisco-dev2dev > > > > _______________________________________________ > oprofile-list mailing list > oprofile-list@... > https://lists.sourceforge.net/lists/listinfo/oprofile-list

Re: non-stripped file for symbol-based profiling From: Maynard Johnson <maynardj@us...> - 2011-08-16 15:54 Maynard Johnson wrote: > hwyang wrote: >> Hello, >> >> >> >> I am try to use OProfile on embedded system boards. I want collect data on >> the target board and produce summaries on my host. My question is that do I >> need to prepare non-stripped images both on the target board and my host OR >> just on my host. Thanks a lot for any reply. > It would have been nice if someone from the oprofile community with embedded experience had replied to you, but since that doesn't seem to be happening, I'll give you some advice. Yes, you can run stripped binaries on your target. After running the profile session, use oparchive to package up all the binaries and sample data needed for post-processing on your host system. After extracting the data on your host system, run opreport something like the following: > > 'opreport --symbols archive:<path-to-oparchive-extract-dir>' > > Now, with a stripped binary, your symbols report won't actually show symbols without some extra steps. There are different ways you can provide the debuginfo that opreport needs. You can use the brute force method and simply replace the stripped binary in question (found within the path-to-oparchive-extract-dir on your host system) with a non-stripped binary. One minor downside to that is opreport is going to complain that this binary doesn't seem to be the one used when the profile was taken. The preferred method (in my mind) is to use objcopy: 1) Use '--only-keep-debug' to create a <binary-name>.debug file; 2) use '--strip-all' to strip your runtime binary; and 3) use '--add-gnu-debuglink' to add a link in your runtime binary to the <binary-name>.debug file. Then, after collecting the profile and using oparchive, extract the archive on your host system and copy the *.debug file(s) to a location where oprofile can find it(them). The location can either be the same di > rectory as the runtime binary (again, within the path-to-oparchive-extract-dir on your host system) or you can create a debuginfo directory within the path-to-oparchive-extract-dir and pass that fully-qualified path (minus the top-level archive extraction destination directory) to opreport using the '--image-path' option. > > Example: You use the above objcopy steps to create a foo.debug file for a stripped runtime binary 'foo'. On the target system, 'foo' is placed in /apps/tests. After running oprofile on the target system, you run oparchive to create an archived directory. You tar up that directory and extract the tar file to /my/home/arch1 on your host system. Then create a /my/home/arch1/apps/debuginfo directory and place your foo.debug files there. You would run opreport as follows: > > 'opreport --symbols archive:/my/home/arch1 --image-path=/apps/debuginfo ./apps/test/foo' --^ No dot! :-/ Another tip: Depending on the architectures of your target and host systems, you may have to run opimport on the sample data you archived from the target and extracted onto your host. See http://oprofile.sourceforge.net/doc/opimport.html. -Maynard > > -Maynard >> >> >> >> BR, >> >> HW >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, >> user administration capabilities and model configuration. Take >> the hassle out of deploying and managing Subversion and the >> tools developers use with it. >> http://p.sf.net/sfu/wandisco-dev2dev >> >> >> >> _______________________________________________ >> oprofile-list mailing list >> oprofile-list@... >> https://lists.sourceforge.net/lists/listinfo/oprofile-list > > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > oprofile-list mailing list > oprofile-list@... > https://lists.sourceforge.net/lists/listinfo/oprofile-list

RE: non-stripped file for symbol-based profiling From: hwyang <hw.yang@ms...> - 2011-08-17 16:18 Dear Maynard, Actually I am trying to use OProfile on Android platform and it uses "opimport" to retrieve data from the target board to the host. But when I use "opreport", it says the binary didn't match with the sampled one. I guess "--add-gnu-debuglink" can solve this problem. I will try it. Thanks a lot for ur reply! Best Regards, HW -----Original Message----- From: Maynard Johnson [mailto:maynardj@...] Sent: Tuesday, August 16, 2011 11:53 PM To: hwyang Cc: oprofile-list@... Subject: Re: non-stripped file for symbol-based profiling Maynard Johnson wrote: > hwyang wrote: >> Hello, >> >> >> >> I am try to use OProfile on embedded system boards. I want collect data on >> the target board and produce summaries on my host. My question is that do I >> need to prepare non-stripped images both on the target board and my host OR >> just on my host. Thanks a lot for any reply. > It would have been nice if someone from the oprofile community with embedded experience had replied to you, but since that doesn't seem to be happening, I'll give you some advice. Yes, you can run stripped binaries on your target. After running the profile session, use oparchive to package up all the binaries and sample data needed for post-processing on your host system. After extracting the data on your host system, run opreport something like the following: > > 'opreport --symbols archive:<path-to-oparchive-extract-dir>' > > Now, with a stripped binary, your symbols report won't actually show symbols without some extra steps. There are different ways you can provide the debuginfo that opreport needs. You can use the brute force method and simply replace the stripped binary in question (found within the path-to-oparchive-extract-dir on your host system) with a non-stripped binary. One minor downside to that is opreport is going to complain that this binary doesn't seem to be the one used when the profile was taken. The preferred method (in my mind) is to use objcopy: 1) Use '--only-keep-debug' to create a <binary-name>.debug file; 2) use '--strip-all' to strip your runtime binary; and 3) use '--add-gnu-debuglink' to add a link in your runtime binary to the <binary-name>.debug file. Then, after collecting the profile and using oparchive, extract the archive on your host system and copy the *.debug file(s) to a location where oprofile can find it(them). The location can either be the same di > rectory as the runtime binary (again, within the path-to-oparchive-extract-dir on your host system) or you can create a debuginfo directory within the path-to-oparchive-extract-dir and pass that fully-qualified path (minus the top-level archive extraction destination directory) to opreport using the '--image-path' option. > > Example: You use the above objcopy steps to create a foo.debug file for a stripped runtime binary 'foo'. On the target system, 'foo' is placed in /apps/tests. After running oprofile on the target system, you run oparchive to create an archived directory. You tar up that directory and extract the tar file to /my/home/arch1 on your host system. Then create a /my/home/arch1/apps/debuginfo directory and place your foo.debug files there. You would run opreport as follows: > > 'opreport --symbols archive:/my/home/arch1 --image-path=/apps/debuginfo ./apps/test/foo' --^ No dot! :-/ Another tip: Depending on the architectures of your target and host systems, you may have to run opimport on the sample data you archived from the target and extracted onto your host. See http://oprofile.sourceforge.net/doc/opimport.html. -Maynard > > -Maynard >> >> >> >> BR, >> >> HW >> >> >> >> >> >> ---------------------------------------------------------------------------- -- >> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, >> user administration capabilities and model configuration. Take >> the hassle out of deploying and managing Subversion and the >> tools developers use with it. >> http://p.sf.net/sfu/wandisco-dev2dev >> >> >> >> _______________________________________________ >> oprofile-list mailing list >> oprofile-list@... >> https://lists.sourceforge.net/lists/listinfo/oprofile-list > > > ---------------------------------------------------------------------------- -- > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > oprofile-list mailing list > oprofile-list@... > https://lists.sourceforge.net/lists/listinfo/oprofile-list

609 messages have been excluded from this view by a project administrator.