On 10/28/12 16:30, Laszlo Ersek wrote: > 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).
(sorry, driver writers' guide) > > 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
