On Thu, January 26, 2012 02:09, Denys Vlasenko wrote: > 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. Thanks, getting the old TID is useful, that was the missing bit to handle execve statelessly. > > >> > 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. The question is how many of those have a different ABI and can not be reliably detected at system call entry time. If the ABI can't be changed at runtime then there's no problem either. x86_64's case is very peculiar because it can execute a 32-bit compat syscall while the process itself is in 64-bit mode. > 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 Fow most of them you can reliably check the mode by looking at registers. x86_64 and apparently ARM are problematic. Others may too in similar subtle ways as x86_64, but I can't tell that from strace's code. ARM looks ok when old cruft isn't enabled (much more likely than compat mode being disabled in x86_64). Can SPARC change mode on the fly without detection? Otherwise it looks like it may be slightly problematic too, though it seems that at least the ABI is pretty much the same between 32 and 64 bit mode. Same for PA-RISC. So all in all not sure if they have a problem or not. To be a problem the only way to figure our what mode the system call will be is by looking at the trapping/syscall instruction itself. If that isn't needed, or if there isn't much difference between the modes anyway, then there's no problem. > > Do you want to re-invent a different arch-specific way to report > syscall type for each of these arches? Thing is, it is not just 32 versus 64 bit mode. So one way or the other, you do end up with an arch-specific way of saying what syscall type it is. It doesn't matter much where that info is stuffed, it will always be arch specific, because depending on that value people have to do different arch specific things. It's fine to somehow give that info together with PTRACE_EVENT_SYSCALL_ENTRY, but I don't think it's a good idea to have different syscall entry events depending on what type they are. I suppose the only reason to do that would be because we're running out of bits elsewhere. > >> 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. If the problem is limited to only a couple of archs, and we can stuff this info in the register set for all of them, then I'm all for it. So far it's just x86_64 and ARM with OABI enabled, with the rest either fine or unclear. Greetings, Indan -- 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
