Maybe this is a side effect of using a backport of the 2.5 interface in
a 2.4 kernel. However, on the ia64 the backport is definitely getting
the the app_name wrong and it looks like the same problem that I
encountered with the earlier version of oprofile running on ia64. I am
looking at fs/proc/base.c:proc_exe_link() to see how that works. The
/proc/[0-9]+/exe seem to be correct.
Philippe Elie wrote:
> William Cohen wrote:
>> I noticed that get_exec_dcookie() in kernels
>> drivers/oprofile/buffer_sync.c has the same assumption as the older
>> oprofile module about where the program executable appears in the list
>> of mappings. This presents a problem on the ia64. The ia64 kernel
>> often places the mapping for the executable later in the list of
>> mappings after other executable mapping, e.g. shared libraries. Thus,
>> a shared libraries gets listed as the app_name rather than the correct
>> executable. Any thoughts on how to remove this assumption?
> I don't think so: 2.4 module is looking for mapping with
> VM_EXEC flags whilst 2.5 module look for mapping with
> VM_EXECUTABLE flags, look fs/proc/base.c:proc_exe_link()
> which determine /proc/pid/exe symlink.