Date:	Sat, 13 Feb 2010 04:41:31 -0500
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Roland McGrath <roland@...hat.com>
Cc:	Christoph Hellwig <hch@....de>, oleg@...hat.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	uclinux-dist-devel@...ckfin.uclinux.org
Subject: Re: [PATCH 1/2] Blackfin: initial tracehook support

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists