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 Xu
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
