On Fri, Feb 12, 2010 at 15:44, Roland McGrath wrote: > Moreover, the usual cleanup is to make your arch_ptrace() use > copy_regset_from_user() and copy_regset_to_user() to implement existing > calls ike PTRACE_GETREGS. That way, existing ptrace users (strace, gdb) > become tests of the user_regset paths (some of them). OK, this should be doable. are there any guidelines for what should be in a specific regset ? the Blackfin processor does not have a FPU, so the only set i have defined atm is the "general" set and that is exactly the same as the current set of ptrace registers. this is also what the current PTRACE_{G,S}ETREGS operates on (struct pt_regs). there are more pseudo regs as required by FDPIC, but they arent in the pt_regs layout ... > What happens today when PTRACE_SINGLESTEP is used with the PC sitting at a > syscall instruction? If that gets a single-step report (SIGTRAP) after the > syscall is done, with the PC sitting at the instruction immediately > following the syscall instruction, then you are already doing the right > thing. On some other machines, making that happen involves arch assembly > code making sure it gets to its syscall_trace_leave() for this case. i believe the single step exception is taken first and then the syscall exception, but i'll have to do some hardware tests on the hardware to confirm >> also, in reading the kerneldocs for tracehook_report_syscall_exit(), >> it says "an attempted system call". should system calls greater than >> NR_syscall (-ENOSYS) also get traced ? we dont currently do this on >> the Blackfin port, but going by `strace` differences between my >> desktop and the board, i guess the answer is "the Blackfin code is >> currently broken". > > Yes. It's any syscall attempt. Inside tracehook_report_syscall_entry(), > all the registers can be changed (via user_regset, i.e. ptrace) so that > what starts as an entry with a bogus syscall number becomes an entry with a > different syscall number and/or arguments. So you can't decide before > tracehook_report_syscall_entry() whether it is "real" or not. For every > tracehook_report_syscall_entry() call, there must be a corresponding > tracehook_report_syscall_exit() call (unless TIF_SYSCALL_TRACE was cleared > in the interim). At that exit point, the registers can again be changed. > > For example, an "expected" use (that some things do today via ptrace) is to > catch the entry, abort the syscall by changing the syscall number register > to something bogus like -1, resume so it diagnoses -ENOSYS and gets to > syscall exit, then catch the exit and reset the return value registers to > pretend some particular syscall results happened. i fixed the Blackfin code to do NR checking after tracing and now `strace` shows the bad syscall as for register munging, i didnt realize this was accepted practice and something that should actively be supported. i had been toying around locally with optimizing some of the syscall paths by breaking this behavior, so i'll add some comments to prevent any further mucking here. the Blackfin code when traced now does: call tracehook_report_syscall_entry(regs) reload syscall NR and all 6 args from regs if syscall NR is valid, call it if syscall NR is invalid, set return value to -ENOSYS store return value into regs call tracehook_report_syscall_exit(regs) -mike -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html