From: William C. <wc...@nc...> - 2002-09-04 18:14:34
|
John Levon wrote: > On Tue, Sep 03, 2002 at 10:30:04AM -0400, Will Cohen wrote: [snip...] >>There have been some changes to help in the regard, but I don't think >>there has been really a way to test this on x86 machines. From what I >>have seen on the x86 machines the first entry in mmap list is the >>executable, so there isn't much difference between the before and after. >>On the ia64 machine I am using it definitely does not order the mmap >>entries, so things associating shared library samples with an executable >>oprofile gets wrong. > > > Apparently /dev/mem is the first mapping with some X processes (not my > machine which is why I made the error in the first case). Have you > tested current CVS without your change here ? If it's still broken > hopefully Phil can find out what's still going wrong. > > thanks > john > I backed out my change from opd_mapping.c and used the CVS code on the ia64 to see of the mmap problem still existed. The problem for determining the executable name still appears. I turned on "separate samples" in oprof_start to exercise the code, turned on verbose logging, started sampling on the ia64 machine, and started up spec2000. It seems to work for a while, but at some point things go wrong. I did the following to find the mapping information: grep " app " /var/lib/oprofile/oprofiled.log|more Opening image "/boot/vmlinux-2.4.18-e.0.16custom" for app "none" Opening image "/lib/ld-2.2.5.so" for app "/sbin/init" Opening image "/lib/libc-2.2.5.so" for app "/sbin/init" Opening image "/sbin/init" for app "/sbin/init" Opening image "/lib/ld-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libc-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libnss_files-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libnss_nisplus-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libnsl-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libnss_dns-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libresolv-2.2.5.so" for app "/sbin/dhcpcd" ... skip to part where things seems to go wrong ... Opening image "/usr/local/bin/oprofiled" for app "/usr/local/bin/oprofiled" Opening image "/lib/ld-2.2.5.so" for app "/bin/sleep" Opening image "/lib/libm-2.2.5.so" for app "/bin/sleep" Opening image "/lib/librt-2.2.5.so" for app "/bin/sleep" Opening image "/lib/libc-2.2.5.so" for app "/bin/sleep" Opening image "/lib/libpthread-0.9.so" for app "/bin/sleep" Opening image "/bin/sleep" for app "/bin/sleep" Opening image "/lib/ld-2.2.5.so" for app "none" Opening image "/usr/bin/expr" for app "/lib/ld-2.2.5.so" Opening image "/lib/libc-2.2.5.so" for app "/lib/ld-2.2.5.so" Opening image "/root/benchmarks/spec_cpu_2000_v1.1-CDROM/bin/specperl" for app "/lib/ld-2.2.5.so" Opening image "/lib/libnsl-2.2.5.so" for app "/lib/ld-2.2.5.so" Opening image "/usr/lib/libdb2.so.3" for app "/lib/ld-2.2.5.so" Opening image "/usr/lib/libgdbm.so.2.0.0" for app "/lib/ld-2.2.5.so" Opening image "/lib/libdl-2.2.5.so" for app "/lib/ld-2.2.5.so" Opening image "/lib/libm-2.2.5.so" for app "/lib/ld-2.2.5.so" Opening image "/lib/libcrypt-2.2.5.so" for app "/lib/ld-2.2.5.so" Opening image "/root/benchmarks/spec_cpu_2000_v1.1-CDROM/bin/lib/5.00503/ia64-linux/auto/IO/IO.so" for app "/lib/ld-2.2.5.so" Notice that image "/usr/bin/expr" has app "/lib/ld-2.2.5.so" and from then on the app name seems to be wrong most of the time. There is still some problems with the way mapping to executable name is done. Thus, the following ChangeLog entry doesn't fix the problem on ia64 machines. 2002-08-06 Philippe Elie <ph...@wa...> * dae/opd_parse.c: * dae/opd_proc.c: * dae/opd_proc.h: fix #591275 which is a re-hash of #584723 we can now safely assume than proc->maps[0] is the primary image. Problem reported by William cohen -Will |