On 12/03, u3...@miso.sublimeip.com wrote: > > > However. Of course it would be nice to avoid the new option. IMO it > > would be better to do nothing ;) vsyscall is deprecated, and EMULATE > > is x86-specific. > > The problem is that the current static glibc invokes the vsyscall page,
Yes I know. Still I'd like to avoid to change the ptrace API, even if the change is simple. This emulate_vsyscall() is too "exotic" imho. > > You forgot again that EMULATE does not execute the code in the > > vsyscall page. > > The beauty of using the x86 debug-registers, is that they do not > trap the instruction, but rather the fact that the program-counter > has a given value. Yes, I understand, so DR_RW_EXECUTE should probably work. And I even sent the patch (untested/uncompiled). But given that even the simple bugfix which started this thread was ignored by maintainers, I am not sure how we can convince them this change makes sense ;) However. This looks like a hack to me, because this code is never executed. But this is sudjective and I am not saying this can't work. And yes, this doesn't add new ptrace hacks. But If we want to allow to trace vsyscall's, hw bp doesn't look very nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all. And what about strace? It won't be easy to change it to use hwbp. That is why I think PTRACE_SYSCALL should "simply work" somehow. And so far I think that "just report syscall_exit with orig_ax = -1" is the best (and simple) solution. OK. We can do more. We can report both syscall_enter/exit and we can change orig_ax/ax temporary to "fool" the tracer, so that everything will look as a "normal" syscall. Like vsyscall_seccomp() does. But this needs much more changes. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
