Prashant Vaibhav wrote: > ...and that is _exactly_ what I propose(d) in the beginning and what OSX > already does. Further, keeping the shared page and functions fixed at the > end of the memory space has advantages like not needing any special linking, > being easily accessible for code jumps or data reads, and so on [1]. The TSC > issues are but one part of the puzzle. > After this week-long discussion I still can't decide whether this was > something that's desirable at all: keeping in mind that it's among the few > project ideas tagged as "Suggested for Google Summer of Code 2009" on the > FreeBSD website. :-\ Though I've been reading mailing list archives, and > the various handbooks, I'm not familiar well enough with other parts of the > freebsd kernel to draft another concrete proposal on my own at this time. > > [1] *Mac OS X Internals: A Systems Approach,* p 595, Amit Singh, ISBN > 0321278542 > > Without using ELF, but using signal like trampoline code as we current do makes it very difficult for some language to do asynchronous stack unwinding, e.g pthread async cancellation and C++ objection destruction. See my recent work for pthread cancellation and stack unwinding: http://people.freebsd.org/~davidxu/patch/unwind.patch Check x86_64_fallback_frame_state() to see what hacking code should be written. Regards, David XuReceived on Tue Mar 31 2009 - 00:38:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC