From: Michael C. <mb...@pr...> - 2011-08-26 21:42:01
|
Greetings, I finally have oprofile building for an ARM platform running linux-2.6.35.7 but I'm having problems with the vmlinux file. I've tried several ways to supply oprofile with a vmlinux file but it always rejects them: MEC1:~ # modprobe oprofile oprofile: hardware counters not available oprofile: using timer interrupt. MEC1:~ # opcontrol --vmlinux=/boot/1-vmlinux MEC1:~ # opcontrol --start The specified file /boot/1-vmlinux does not seem to be valid Make sure you are using the non-compressed image file (e.g. vmlinux not vmlinuz) I've read online that one must use objcopy to produce the file. (Since this is a cross compile I'm using the cross-objcopy). But I cannot find documented exactly what file in the linux kernel tree to copy from nor what objcopy options to use. I've tried no options and got the error above and I tried "-O binary" and it produced a 3.1GB file that NFS couldn't even convey. Can someone provide complete guidance on what/how to produce the needed vmlinux? The filename itself doesn't matter, does it? Are there any steps I can use to get more information than "does not seem to be valid"? Thanks for any assistance! -Mike |
From: William C. <wc...@re...> - 2011-08-29 13:38:02
|
On 08/26/2011 05:41 PM, Michael Cashwell wrote: > Greetings, > > I finally have oprofile building for an ARM platform running linux-2.6.35.7 but I'm having problems with the vmlinux file. I've tried several ways to supply oprofile with a vmlinux file but it always rejects them: > > MEC1:~ # modprobe oprofile > oprofile: hardware counters not available > oprofile: using timer interrupt. > MEC1:~ # opcontrol --vmlinux=/boot/1-vmlinux > MEC1:~ # opcontrol --start > The specified file /boot/1-vmlinux does not seem to be valid > Make sure you are using the non-compressed image file (e.g. vmlinux not vmlinuz) > > I've read online that one must use objcopy to produce the file. (Since this is a cross compile I'm using the cross-objcopy). > > But I cannot find documented exactly what file in the linux kernel tree to copy from nor what objcopy options to use. I've tried no options and got the error above and I tried "-O binary" and it produced a 3.1GB file that NFS couldn't even convey. > > Can someone provide complete guidance on what/how to produce the needed vmlinux? > > The filename itself doesn't matter, does it? > > Are there any steps I can use to get more information than "does not seem to be valid"? > > Thanks for any assistance! > -Mike Hi Mike, Is there a vmlinux file in directory that you cross-compiled the kernel? You should be using that file. You should be able to just "cp" or "scp" the file to a place that is visible to the target machine. Then use "--vmlinux=<path_to_vmlinux_file>". -Will |
From: Michael C. <mb...@pr...> - 2011-08-30 19:36:38
|
On Aug 29, 2011, at 9:37 AM, William Cohen wrote: > On 08/26/2011 05:41 PM, Michael Cashwell wrote: >> MEC1:~ # opcontrol --start >> The specified file /boot/1-vmlinux does not seem to be valid >> Make sure you are using the non-compressed image file (e.g. vmlinux not vmlinuz) > > Hi Mike, > > Is there a vmlinux file in directory that you cross-compiled the kernel? You should be using that file. You should be able to just "cp" or "scp" the file to a place that is visible to the target machine. Then use "--vmlinux=<path_to_vmlinux_file>". OK, after a yak-shave of epic proportions, this ended up being a borked install of binutils on my target causing objdump to not be able to run. Documentation that says "yum install binutils-devel" is not really very helpful on embedded systems where we build everything from source. Thanks for the vmlinux tips. As it turns out the one I originally tried was fine once objdump worked. Then, once I realized that specifying a --session-dir=... in opcontrol does not seem to convey to opreport. Sigh. Really? There's a day I won't get back... I have it working to some degree. My target is a ARM Xscale-PXA-270. /proc/cpuinfo (from 2.6.35.7) says: Processor : XScale-PXA270 rev 8 (v5l) BogoMIPS : 103.76 Features : swp half fastmult edsp iwmmxt CPU implementer : 0x69 CPU architecture: 5TE CPU variant : 0x0 CPU part : 0x411 CPU revision : 8 and I see lots of event types defined for ARMv7, xscale1 and xscale2. I'm uncertain if those apply but I'm a little surprised to find that opcontrol --list-events says "Using timer interrupt." and nothing else. Is that right? Lastly, I'm having the devil of a time trying to get a useful view of the results. I have an app that's consuming about half of the CPU but I can't seem to get a sorted list of *where* (including the calling stack trace) that time is being spent. I've only been working this for a little while so I'll continue on. Thanks for the info! -Mike |
From: William C. <wc...@re...> - 2011-08-30 20:05:39
|
On 08/30/2011 03:36 PM, Michael Cashwell wrote: > On Aug 29, 2011, at 9:37 AM, William Cohen wrote: > >> On 08/26/2011 05:41 PM, Michael Cashwell wrote: >>> MEC1:~ # opcontrol --start >>> The specified file /boot/1-vmlinux does not seem to be valid >>> Make sure you are using the non-compressed image file (e.g. vmlinux not vmlinuz) >> >> Hi Mike, >> >> Is there a vmlinux file in directory that you cross-compiled the kernel? You should be using that file. You should be able to just "cp" or "scp" the file to a place that is visible to the target machine. Then use "--vmlinux=<path_to_vmlinux_file>". > > OK, after a yak-shave of epic proportions, this ended up being a borked install of binutils on my target causing objdump to not be able to run. Documentation that says "yum install binutils-devel" is not really very helpful on embedded systems where we build everything from source. > > Thanks for the vmlinux tips. As it turns out the one I originally tried was fine once objdump worked. > > Then, once I realized that specifying a --session-dir=... in opcontrol does not seem to convey to opreport. Sigh. Really? There's a day I won't get back... I have it working to some degree. > opreport doesn't have permission to read /root/.oprofile/daemonrc where opcontrol stores that information. We need to revisit how and where that configuration information is stored. Making opreport "just work" would simplify things. > My target is a ARM Xscale-PXA-270. /proc/cpuinfo (from 2.6.35.7) says: > > Processor : XScale-PXA270 rev 8 (v5l) > BogoMIPS : 103.76 > Features : swp half fastmult edsp iwmmxt > CPU implementer : 0x69 > CPU architecture: 5TE > CPU variant : 0x0 > CPU part : 0x411 > CPU revision : 8 > > and I see lots of event types defined for ARMv7, xscale1 and xscale2. I'm uncertain if those apply but I'm a little surprised to find that opcontrol --list-events says "Using timer interrupt." and nothing else. Is that right? It is going to depend a lot on which kernel is being used and how the kernel build was configured. There has been a lot of reworking of the arm oprofile support to use the perf infrastructure: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=arch/arm/oprofile;hb=HEAD The 2.6.35 kernel uses the perf infrastructure: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/oprofile/common.c;h=c074e66ad224e83d18d1f278afc78aa00e18b494;hb=0f43dd546d991ca260d8a72d07f617907c508de8 Is CONFIG_HW_PERF_EVENTS set in the .config file? If not, oprofile is going to fall back to the timer mode. > Lastly, I'm having the devil of a time trying to get a useful view of the results. I have an app that's consuming about half of the CPU but I can't seem to get a sorted list of *where* (including the calling stack trace) that time is being spent. I've only been working this for a little while so I'll continue on. I am not sure how well the stack back tracing works on arm. On x86 processors there are problems if the framepointer is omitted in the compiled code due to the defaults (-fomit-frame-pointer). If time is being spent in a shared library you might want to use "--separate=library" in the opcontrol setup or if it is in kernel function "--separate=kernel" map the samples back to an executable. > Thanks for the info! > > -Mike > The kernel is new enough you might also try the linux kernel perf. -Will |