On Sun, 2013-01-20 at 15:41 -0500, Joe Vernaci wrote: > Could this cause unaligned memory accesses? This is fine for x86/x86_64, > could cause a fault on Itanium, and will always cause a fault on EBC. It > would be a pretty remote use case but still could happen.
Potentially, yes. For GCC we could also mark the PCI_DATA_STRUCTURE and PCI_3_0_DATA_STRUCTURE with __attribute__((packed)) and that would ensure that it emits appropriate code to handle unaligned accesses. If we have to use a less capable toolchain it probably gets more fun, and we might need to have accessor macros which do the same thing 'long-hand'. Or we could relax the constraints but only for x86. Or we could just not do it at all, and fix the offending OpRoms. Which is fine for the one I *found* (I've already submitted the patch) but I don't actually know if this is seen in the wild on real hardware. It *might* be widespread; I very much doubt traditional BIOSes have been picky about it. Since it's a pointer they follow, they'd have to go out of their way to enforce standards-compliance — which isn't exactly their normal modus operandi. It's not like it's a magic structure that they *search* for, which would mean that they'd only find it if they did a byte-by-byte search instead of the more efficient word-by-word or para-by-para or whatever the expected alignment was. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012
_______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
