On Thursday 26 January 2012 01:40, Indan Zupancic wrote: > >> We can add the new events, > >> > >> PTRACE_EVENT_SYSCALL_ENTRY > >> PTRACE_EVENT_SYSCALL_COMPAT_ENTRY > >> PTRACE_EVENT_SYSCALL_EXIT > >> PTRACE_EVENT_SYSCALL_COMPAT_EXIT > > > > We can get away with just the first one. > > (1) It's unlikely people would want to get native sysentry events but not compat ones, > > thus first two options can be combined into one; > > True. > > > (2) syscall exit compat-ness is known from entry type - no need to indicate it; and > > (3) if we would flag syscall entry with an event value in wait status, then syscall > > exit will be already distinquisable. > > False for execve which messes everything up by changing TID sometimes. Dealt with in Linus tree already: set PTRACE_O_TRACEEXEC option, and use PTRACE_GETEVENTMSG in PTRACE_EVENT_EXEC stop to get the old TID. > > To future-proof this scheme we may reserve a few more event values > > PTRACE_EVENT_SYSCALL_ENTRY2, PTRACE_EVENT_SYSCALL_ENTRY3, etc, > > if we'll ever have arches with more than one non-native syscall > > entry. I'm no expert, but looking at strace code, ARM may already have > > more than one additional convention how to pass syscall args. > > Please, no! This way lays madness, just one PTRACE_EVENT_SYSCALL_ENTRY, > no PTRACE_EVENT_SYSCALL_ENTRY1 or PTRACE_EVENT_SYSCALL_ENTRY2, that > would be horrible. Keep arch specific stuff in arch specific areas, > please don't spread it around. The situation when an architecture has 32- and 64-bit varieties, and sometimes different ABIs (parameter passing comventions), is rather typical, it's not a quirk of just one unfortunate architecture. Please look at strace source, get_scno() function, where it reads syscall no and parameters. Let's see.... - POWERPC: has 32-bit and 64-bit mode - X86_64: has 32-bit and 64-bit mode - IA64: has i386-compat mode - ARM: has more than one ABI - SPARC: has 32-bit and 64-bit mode Do you want to re-invent a different arch-specific way to report syscall type for each of these arches? > What was wrong with using eflags again? Is it too simple or something? It's x86-specific, and abuses a bit in a real register. -- vda -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
