Re: getcontext() -> Bus error?
Re: getcontext() -> Bus error?
- Subject: Re: getcontext() -> Bus error?
- From: Edd Dawson <email@hidden>
- Date: Sat, 16 Feb 2008 21:23:52 +0000
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.
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?
> 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.
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.
Kind regards,
Edd
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden