Re: FW: OProfile 0.7.1 problem on profiling 32-bit app on 64-bit OS

[Philippe E. <ph...@wa...>]

On Mon, 15 Mar 2004 at 22:30 +0000, ree...@am... wrote:

> Hi Phil,
> 	I am working on this oprofile issue and I compared oprofile.log
> for the two cases. These are my findings.
>
>  case1: "/devel/example" starts before opcontrol --start. In this
> case oprofile reads  cat /proc/$(pidof example)/maps finds two
> application mappings say map1 and map2 along with mapping of different
> libraries.
>
>  case2: "/devel/example" starts after opcontrol --starts. In this case
> oprofiled.log logs two DO_EXEC operation after the FORK opeation,
> which does not happen for any other process. You can see the attached
> log file.
> When we start "example" in a console, all the previos images associated
> with /bin/bash are deleted and a new primary image /devel/example and a
> new mapping map1 is made. oprofiled.log immediatly reports another
> DO_EXEC and deletes the prevous map1 and image /devel/example and create
> another map2 and another primary image /devel/example. Oprofile records
> all the "/devel/example" samples in map1 ,but can not report it, since
> it deleted map1.
>
> When I traced this back to kernel module oprofile this is happening
> because oprof_output_maps() function in hammer_op_syscalls.c finds two
> maps at mm->mmap with flag VM_EXECUTABLE and report each of them as
> OP_EXEC opeation to the daemon. This was not happening in oprofile
> 0.5.4 because it always assumed  first as OP_EXEC map and rest of them
> as OP_MAP. This kept the map1 and since all the example samples are from
> map1, it reported. This seems  changed in 0.7.1 becase of some other
> issue. When I tried with "/devel/example64, same application compiled
> as a 64bit application it generated only one map. I am not much familier
> with how 32bit applications handled in Linux kernel. Any suggestions
> appreciated about how this issue can be fixed to accomodate 32bit
> application.

Exactly the information I need!

Try this patch, it assumes the first map with a VM_EXECUTABLE
bit is the right map for the application itself. I dunno why
the executable is splitted in two maps.

I don't completely understand the log file:

DO_EXEC: pid 8981 8981
[delete image from forking application]
Creating image: /devel/example (null), kernel 0, tid 8981, tgid 8981
Adding mapping for process 8981: 0x08048000-0x0804a000, off 0x00000000, "/devel/example"
DO_EXEC: pid 8981 8981
Deleting image: name /devel/example app_name (null), kernel 0, tid 8981, tgid 8981 ref count 1
Creating image: /devel/example (null), kernel 0, tid 8981, tgid 8981
Adding mapping for process 8981: 0x0804a000-0x0804b000, off 0x00001000, "/devel/example"

the two mapping overlap in file:

0x08048000-0x0804a000, off 0x00000000 [ file range 0x0000-0x2000 ]
0x0804a000-0x0804b000, off 0x00001000 [ file range 0x1000-0x3000 ]

what kernel version are you using ?

regards,
Phil

Index: module/x86/hammer_op_syscalls.c
===================================================================
RCS file: /cvsroot/oprofile/oprofile/module/x86/hammer_op_syscalls.c,v
retrieving revision 1.5
diff -u -p -r1.5 hammer_op_syscalls.c
--- module/x86/hammer_op_syscalls.c	19 Jan 2004 20:00:28 -0000	1.5
+++ module/x86/hammer_op_syscalls.c	16 Mar 2004 12:13:16 -0000
@@ -111,6 +111,7 @@ static int oprof_output_maps(struct task
 
 		oprof_output_map(map->vm_start, map->vm_end-map->vm_start,
 			GET_VM_OFFSET(map), map->vm_file, 1);
+		break;
 	}
 	for (map = mm->mmap; map; map = map->vm_next) {
 		if (!(map->vm_flags & VM_EXEC) || !map->vm_file)