Thanks for the feedback, and sorry for the typo in my email address in the
porting howto (I've fixed that).
Any changes I made in arch code were part of mass query-replace changes and
other things I did while grepping for symbols I was removing. I didn't
intend to remove any useful code and anything changing something wrongly
was an error on my part probably due to misunderstanding the arch code.
I was just trying to leave arch's I wasn't porting myself slightly closer
to a compilable state. I'd be glad to amend anything in the patch that is
not right.
I see. I don't understand why you don't use regs->ARM_ORIG_r0 for this,
but I am not the expert. If in fact there is no slot in struct pt_regs
that is right to use, the utrace way to do this is to add another regset
containing just the one word of "syscall about to be made". It only needs
to be meaningfully settable and gettable when at the syscall entry stop.
Your PTRACE_SET_SYSCALL support would use this.
We can change the signature to (struct task_struct *, struct pt_regs *).
Then following the above plan it can do tsk->thread.syscall = -1.
What those remarks mean is that UTRACE_ACTION_SINGLESTEP will only ever be
for something with semantics like hardware single-step support has, i.e. no
side effects on memory or anything else outside the thread's CPU state.
That is not to say that software single-step will never be implemented in
the utrace world.
What you need is temporary breakpoint insertion, ideally a breakpoint that
would be per-thread. Eventually we will have a general facility based on
utrace that provides breakpoints, and later per-thread breakpoints, and it
will get improved over time. New things using utrace can see
ARCH_HAS_SINGLE_STEP not set and fall back to using breakpoint insertion,
and they will know the different ramifications it might have on the
semantics or performance compared to a machine where UTRACE_ACTION_SINGLESTEP
is available. ptrace can be like this when that infrastructure is available.
In the meantime, ptrace alone can use the old code and nothing is lost.
If that's the worst problem you have, we're in fat city! I think it's good
to reduce linux/ptrace.h includes so the dependency goes away from every
place not actually dealing with ptrace. The trap frame struct pt_regs is
traditionally defined in asm/ptrace.h, so that needs to be included in a
lot of places, but linux/ptrace.h is just ptrace hooey nothing much inside
the kernel needs to see.
Thanks,
Roland
-
