site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Thunderbird 2.0.0.9 (Windows/20071031) Hi Terry, Thanks for your patient response. I really appreciate it. Terry Lambert wrote:

When you call getcontext/makecontext/setcontext, you are hacking the contents of your context. This includes register and other state, including the stack register. This makes sense, since these functions are typically used to implement user space threads schedulers. This is what I'm doing (user space threads). Then you go and depend on the contents of a value which is either stack relative, or which has been loaded into a volatile register, and expect the code to "do the right thing", even though you are saying something like "load a bunch of stack relative data off an offset of -256 off the stack" (or whatever), or you are saying "load a bunch of data relative the the address contained in register such-and-such I just overwrote". Either of these can now refer to totally different data, but the compiler didn't know about that as a barrier, so it uses the stale contents not knowing the contents of what it is using was changed out from under it. Either way you look at it, this stuff is going to break under those conditions.

Minimally, you should be using a chunk of heap or global data, the address of which is contained in a variable that has been declared "volatile" so that (a) it will be passed to the functions in a volatile register, and (b) after the function returns, it doesn't try to pop data from the stack back into the register, particularly because your new stack doesn't have the saved data on it anyway, and even if it did, the data it wants to pop back only exists on the old stack, which you are no longer referencing. Ok, thank you. I shall make the appropriate changes. I think on other systems you are simply lucking out due to internal implementation, or your compiler is doing different optimizations by default.

Using functions like these correctly will generally take a pretty fundamental understanding of the machine architecture, the assembly code that will be emitted by your compiler, and the relevant standards governing the functions behaviour. Kind regards, Edd

Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I can see how what I did would be problematic for certain implementations. On the other hand I don't believe I'm doing anything funny as far as the POSIX standard is concerned. Please excuse the naivety of this next question as I'm not well read on the low level details, but running with your example, would absolute offsets not be necessary rather than relatives to ensure POSIX compliance? Well, I was under the impression that the relevant standard was POSIX and that my expectations were in line with its wording. Have I missed something? I thought the whole point of these functions was to provide a layer of abstraction so relative laymen such as myself don't have to worry about compiler/target-architecture details. This email sent to site_archiver@lists.apple.com