Hi all, Thank you for the responses.
I'll try to read more on the related matters. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tim Bird Sent: Friday, 28 September, 2012 2:49 AM To: [email protected] Cc: Takuo Koguchi Subject: Re: [android-kernel] system call log interpretation On 09/26/2012 07:35 PM, Takuo Koguchi wrote: > 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. Well, you learn something new every day! I didn't know ARM *had* private syscalls. Thanks for this info. BTW - this is used in the bionic routine cacheflush(), located in bionic/libc/arch-arm/syscalls/cacheflush.S I couldn't find any callers of cacheflush() in bionic. It's also called via the syscall() syscall in valgrind, but with cursory poking about I couldn't find any other references in AOSP. Presumably the original app knows what it's doing, or some library routine is invoking this. It seems like a lot of overhead to go to the kernel to guarantee a cache flush. Maybe this is related to some kind of user-space locking primitive. Interesting diversion... -- 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
