Ingo Molnar wrote:
> > Good point. You can bet that some partial machine code evaluator
> > would like to disassemble the vsyscall code and duplicate the
> > equivalent in JIT generated code at some point, interleaved with
> > caller optimisations...
>
> yep - since kernel-entry-less vsyscalls are basically an extension to
> glibc, it's perfectly possible to avoid the intended behavior via
> user-space tricks. Just like it's possible currently to override the _time
> libc function.
It's not meant to avoid intended behaviour -- merely to optimise it.
Currently you can take _any_ user space code and without too much
difficulty, analyse, duplicate and optimise the code to get equivalent
functionality.
However syscalls enter the kernel whose code cannot itself be analysed
(in the system I am thinking of), but modify the user space memory map.
So a dynamic optimiser does have to have some idea what syscalls do.
> So anyone who wants to do tricks must either do it at the
> libc level if vsyscalls are use.
Indeed the dynamic optimiser should probably be told not to mimic the
vsyscall page, but to always call it. In other words, the vsyscall page
is a special case for the dynamic optimisation rules.
That's fair enough, as it has to know about syscalls in general anyway.
What I would like is a guarantee that if I see this sort of sequence in
vsyscall: "entry: jmp somewhere", then it's ok to jump to "somewhere"
for example. Extend that to partially evaluating the vsyscall table
lookup code -- if, for a given syscall number, the instructions that
execute are quite straightforward, then executing the equivalent sequence
elsewhere will also give correct results.
I think that's easy enough to guarantee.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:17 EST