Messages in this thread | | | Date | Tue, 19 Nov 2013 20:10:34 +0100 | From | Andi Kleen <> | Subject | Re: [PATCH] Add a text_poke syscall |
| |
> Design: more fundamentally, you don't explain the design: why is this > architecture specific and why is it a new syscall? > > In particular I'm somewhat sceptical about doing this as a separate > syscall, because such Linux-only syscall specials tend to propagate to > the right tools rather slowly - especially if it's an x86-only > Linux-special syscall ...
Self modifying code is by definition x86 specific.
Very likely any other method to do this would be Linux specific in some form or another, as there doesn't seem to be any existing art. > > If we want to do this then it could be shaped as a straightforward > ptrace() extension: ptrace already has the concept of self-tracing > (PTRACE_TRACEME), so adding PTRACE_POKETEXT with pid==0 (or a special > flag to denote 'careful text self-modification') would achieve that, > and would make it instantly available to tooling, without fragile > syscall wrappers.
Hmm, my impression was that ptrace would always stop, but yes that TRACEME thing would be possible. Of course once you do TRACMEME the debugger won't work anymore. But there's no reason for text_poke to exclude debuggers. That would seem like a major disadvantage to me.
My personal feeling is that ptrace is already very complicated, hard to understand and best left alone. So I preferred to do it in a clean separate system call.
But if people really think ptrace is somehow better it would be a possibility.
Is the motivation here just to limit the number of syscalls, or some other reason too?
> That would also allow other SMP architectures with speculative > execution to implement such code modification helpers as well, by > reusing the same new ptrace ABI.
They could always add text_poke too. But their requirements may be different (for example they may or may not need the handler) and any code using it would be necessarily architecture specific anyways.
-Andi
-- ak@linux.intel.com -- Speaking for myself only.
| |