On 10/27/12 14:21, Paolo Bonzini wrote: > Il 23/10/2012 02:08, Laszlo Ersek ha scritto: >> That on the other hand casts away the volatile qualification of the >> pointer before the access through it (to an object defined as volatile), >> which explicitly violates C99 6.7.3p5. (See the CopyMem() comment in the >> same file a bit higher up.) >> >> 5 If an attempt is made to modify an object defined with a const- >> qualified type through use of an lvalue with non-const-qualified >> type, the behavior is undefined. If an attempt is made to refer to an >> object defined with a volatile-qualified type through use of an lvalue >> with non-volatile-qualified type, the behavior is undefined. > > Is there a UEFI macro for a compiler optimization barrier? If so, use > it and forget volatile altogether...
Wherever the virtio specification required a memory barrier, I used MemoryFence(). I used volatile wherever I thought it was necessary in combination with MemoryFence. I encountered MemoryFence() first in "4.2.6 Memory ordering" in the UEFI spec (2.3.1). I think the x86_64 / gcc-4.4 implementation of MemoryFence() is in "MdePkg/Library/BaseLib/X64/GccInline.c". Laszlo ------------------------------------------------------------------------------ WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
