[cfe-dev] Which optimization barriers do I need here?

John McCall rjmccall at apple.com
Tue Jan 22 11:17:51 PST 2013


On Jan 18, 2013, at 9:20 AM, Markus Gutschke (顧孟勤) <markus at google.com> wrote:
> I think we don't care about the compiler splitting the store, as long as it isn't interleaved with a system call. Our hook only ever runs as a direct result of an intercepted system call.
> 
> We have some (limited) control over when we output system calls, as we know that basic assignments won't generate system calls behind the scenes. But of course, something like "delete[]" could very legitimately result in system calls. So, our assignment to the pointer has to be completed prior to "delete[]".
> 
> Otherwise, we could end up dereferencing the old pointer from our hook, even though "delete[]" already released the memory.
> 
> Similarly, we have to make sure that "memcpy()" has completed prior to us switching the pointer.
> 
> N.B.: this is all single threaded code and due to the nature of how the sandbox works, we know it will never be changed to be multi-threaded code. So, as far as the CPU is concerned, this is perfectly deterministic code. We don't need to worry about CPU barriers or about effects of the memory model. Neither do we have to worry about any asynchronous events. All we care about are compiler barriers.

asm volatile("":::"memory"); is the traditional compiler optimization barrier and should work fine in this case.

John.



More information about the cfe-dev mailing list