On Thursday, January 09 2014, Roland McGrath wrote: >> I won't argue, but it is not clear to me if this is really useful, >> given that the debugger can read the regs. > > I do see the utility of having a consistent machine-independent way to get > the syscall number from userspace. But note that this could be probably > accomplished with just a uapi header change, providing an inline or macro > to extract the syscall number from the regset data. (It was once the case > that there were some machines where the syscall number is not in any > register and has to be extracted by decoding the instruction. I'm not sure > if that is still an issue anywhere.) > > Also note that adding a separate copy of the syscall number introduces a > new wrinkle into the interface. This might be considered to be good, bad, > or indifferent, but I think it should at least be considered explicitly. > That is, at the entry stop the syscall number (when it's in a register) can > be changed via ptrace. So if the number is delivered via ptrace_message, > that's a separate copy of the original number that does not reflect any > changes made via ptrace--so it reflects what userland asked for, as opposed > to what the kernel actually acted on. > > I don't have a particular opinion about which way to go with that. > I just wanted all the issues (I'm aware of) to be considered.
Hm, thanks for your insights. I don't really have a strong opinion here. I could say that I think ptrace should report the syscall that was originally called (and not the one that will effectively be called), but maybe that would sound like I am defending what I current have, heh... Anyway, one question that I'm having now is what currently happens. Guess I will take a look. Having said that, if adding the syscall number information to ptrace_message is too much controversial, I guess I will abandon this idea for now and just implement the notifications. -- Sergio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
