As already suggested by Glenn, syscall_983042 seems to be an ARM private cacheflush syscall. The number is assigned in arch/arm/include/asm/unistd.h In the case of EABI, __ARM_NR_cacheflush is 0x0f0002(=982042) /* * The following SWIs are ARM private. */ #define __ARM_NR_BASE (__NR_SYSCALL_BASE+0x0f0000) #define __ARM_NR_breakpoint (__ARM_NR_BASE+1) #define __ARM_NR_cacheflush (__ARM_NR_BASE+2) #define __ARM_NR_usr26 (__ARM_NR_BASE+3) #define __ARM_NR_usr32 (__ARM_NR_BASE+4) #define __ARM_NR_set_tls (__ARM_NR_BASE+5)
The strace command used here has no knowledge about the syscall and seems to print the contents of registers from R0. syscall_983042(0x47a8e074, 0x47a8e078, 0, 0xfff, 0x4086d118, 0x47a8e074, 0x47a4a905, 0xf0002, 0, 0x47a8e078, 0xfc46f7bc, 0x413d4630, 0, 0xbeb43678, 0x40841ac3, 0x40011454, 0x40000010, 0x47a8e074, 0xb691, 0, 0x7461642f, 0x61642f61, 0x632f6174, 0x682e6d6f, 0x63646e61, 0x2e746e65, 0x7478656e, 0x2f736d73, 0x755f6368, 0x61, 0, 0) = 0 The syscall number 0xf0002 is stored in R7 as expected. ARM private cacheflush syscall actually takes only 3 args, start(0x47a8e074), end(0x47a8e078), flags(0). 0 is the only valid value for the syscall. So the log entry says, the application requested to write back 4 bytes of data to the memory and it succeded. Hope this will help. Takuo 2012/09/26 22:41 "Tim Bird" <[email protected]>: > On 09/25/2012 06:32 PM, syahaz wrote: > > Dear all, > > > > I would like to seek your help in interpreting the system call log file > in > > android, if you have any experience in doing it. For your information, > I�m > > using the strace to dump the log of an application. > > The example is as follows: > > syscall_983042(0x47a8e074, 0x47a8e078, 0, 0xfff, 0x4086d118, 0x47a8e074, > > 0x47a4a905, 0xf0002, 0, 0x47a8e078, 0xfc46f7bc, 0x413d4630, 0, > 0xbeb43678, > > 0x40841ac3, 0x40011454, 0x40000010, 0x47a8e074, 0xb691, 0, 0x7461642f, > > 0x61642f61, 0x632f6174, 0x682e6d6f, 0x63646e61, 0x2e746e65, 0x7478656e, > > 0x2f736d73, 0x755f6368, 0x61, 0, 0) = 0 > > Appreciate your feedback. > > Thank you. > > This doesn't make any sense. You are using a bunch of words together > that correspond to different systems. I have no idea what a > "system call log file" is. > > You can get an strace dump, using the strace command (which uses > the ptrace system call. You could get the log from the kernel, > which might be instrumented to return system call information. > You can obtain syscall call information from ftrace. Finally, > you could be getting the Android logs for the processes on your > system. > > However, the output above bears no resemblance to any of these > 4 different sources of system information. In particular > it doesn't look like strace output. > > One does not use strace to dumo the log of an application. > One uses strace to trace the system calls of an application. > One uses logcat to dumo the log of an application, and dmesg > to dump the log of the kernel. > > Can you describe what you are doing (or trying to do) in > greater detail? > -- Tim > > ============================= > Tim Bird > Architecture Group Chair, CE Workgroup of the Linux Foundation > Senior Staff Engineer, Sony Network Entertainment > ============================= > > -- > unsubscribe: [email protected] > website: http://groups.google.com/group/android-kernel > -- unsubscribe: [email protected] website: http://groups.google.com/group/android-kernel
