Messages in this thread | | | Date | Tue, 7 Dec 1999 22:41:41 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: What I suspect |
| |
On 7 Dec 1999, Ulrich Drepper wrote: > > > Note that the _real_ reason I originally wanted this is because I hate > > having the sigreturn trampoline on the stack. It's ugly, and is > > conceptually really wrong - the stack shouldn't have to be executable. > > If you would use a recent library you'd see that unless the user does > something stupid there is always a sigreturn handler installed. No > signal handler on the stack.
"Those who do not know history are doomed to repeat it".
The sa_restorer flag isn't new. That's how the original Linux signal return code was marked, and it worked beautifully and linux never scribbled anything on the stack.
Until the sigcontext had to be changed. At which point people still wanted to run old binaries (with an old sa_restorer) yet at the same time have a new signal layout.
The signal stack has actually been fairly static lately, and the rtsigaction() was able to re-introduce this. However, funny that you should mention it, it may be obsoleted _again_ by the fact that KNI needs a different sigcontext layout...
At which point we may have to do the same thing all over again. Except that if we do need this, I _am_ going to go the global page way, because the dynamic code on the stack thing is just too horrible.
> It's already implemented. Similar to Sun's scheme. And it's possible > to completely disable it if you don't need it.
So how did you do it without making process startup slower? I'm genuinely interested. Unless the answer is "we do runtime linking anyway, so we get it for free", in which case it just means that you can never do the _really_ clever thing (ie pre-linked libraries that don't need fixup and thus start up much faster)
Linus
- 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/
| |