On 01/26/2012 08:53 AM, Denys Vlasenko wrote: > On Thu, Jan 26, 2012 at 9:23 AM, Pedro Alves <palves@xxxxxxxxxx> wrote: >> On 01/26/2012 12:59 AM, Jamie Lokier wrote: >>> Tracers mainly want to know if it's a 32-bit or 64-bit syscall, not >>> whether it's compat as such. >> >> Another idea, avoiding new PTRACE_EVENTs per arch, would be to make >> the abi32/abi64/compat/whatnot discriminator retrievable with PTRACE_GETEVENTMSG >> instead. So you'd get PTRACE_EVENT_SYSCALL_ENTRY|EXIT, or the regular old >> 0x80|SIGTRAP, you'd still fetch the syscall number from $orig_ax (or whatever means >> for other archs), as usual, then have extra syscall info in PTRACE_GETEVENTMSG. >> I don't know if it'd be simple to make it possible to do PTRACE_GETEVENTMSG >> on a 0x80|SIGTRAP trap, but I imagine it so. >> >> -> wait >> <- 0x80|SIGTRAP (or PTRACE_EVENT_SYSCALL_ENTRY) >> -> read regs, find out syscall number >> -> PTRACE_GETEVENTMSG, figure out which entry mode was used. > > This would require additional ptrace op per syscall entry. > Linus' method and event method wouldn't. Yes. In any case, ptrace events leave recording the state in core files behind; possibly also important for userspace c/r. Linus' method or a new regset don't have that drawback. A new regset requires an additional ptrace op too, while the former abuses an architecture register, possibly leading to headaches later on. -- Pedro Alves -- 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
