Uli,
can you tell me what the new glibc does for different "clone()" system
calls? It turns out that some of the different process creation calls are
rather nasty to handle with the "call *syscallptr" approach. We have a few
differenct cases:
- vfork() is nasty, because it must not have a stack frame that the
parent needs and that might get destroyed by the child.
- clone(.. newesp != 0 ..) is nasty, because the esp correction depends
on just what kind of system call it was, and the current kernel doesn't
know and really doesn't even _want_ to know.
I know glibc does the inlined "int 0x80" for the vfork() case, but I
wonder if you saw the problem for thread creation? I think that one has to
use the old-style inlined "int 0x80" too in order to avoid stack
confusion.. And since the glibc "clone()" wrapper call gives the user the
option to set a non-zero ESP, that one has to do it too.
(Both of these are really independent of "sysenter" itself, and will be
visible even on machines without any sysenter support, since they are both
stack offset issues caused simply by the fact that we use a trampoline to
jump to the system call).
Comments? Can anybody find any other nasty cases where the stack pointer
matters for the system call (or an argument is used for a start ptr return
value)?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:18 EST