Around 15 o'clock on Feb 19, Stuart Anderson wrote:
> It seems like the wrapped versions could be extended so that they would
> work correctly.
That's not possible. The fundemental problem is that setjmp captures the
execution context (more or less the "continuation") from its caller,
including the stack pointer, frame pointer, register contents and program
counter. When longjmp is executed, all of that context is reloaded into
the CPU and the program resumes execution precisely where setjmp would have
returned.
As the setjmp man page says:
"The stack context will be invalidated if the function which called
setjmp() returns."
So, it's not possible to wrap this function in another function -- the
wrapping function will return and invalidate the stack context preserved
in the jmp_buf. When longjmp happens, the process attempts to return back
inside the setjmp wrapper function except the stack context from that
function has been trashed by other use of the stack after it returned the
first time.
Besides, I don't see how wrapping these functions can solve the portability
issues -- there's no data abstraction presented, only a function
abstraction. The portability issue is over the size of the jmp_buf
datatype, something which is clearly dependent on the libc in use during
execution. Referencing the functions through another name will avoid
collisions with the local C library and provide precisely the same
portability as a wrapper would. One could argue the same should be done
with many other transparent libc wrapper functions without loss of
portability and could reduce the overhead when calling such functions.
One fix that would match the portability assumptions in the current loader
would be to write XFree86-specific versions of setjmp and longjmp in
assembly for each architecture.
-keith
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
