AFAIK the __attribute__((packed)) only allows for unaligned member accesses
but assumes the root of the structure will be aligned. Such as:
typedef struct __attribute__((packed)) {
uint8_t a; // aligned
uint32_t b; // unaligned
uint8_t c;
uint8_t d;
uint8_t e;
uint8_t f;
uint32_t g; // aligned
} mystruct;
mystruct *getptr(void) {
return (mystruct *)0x1;
}
int func(void) {
mystruct *foo = getptr();
foo->a = 0; // special alignment code
foo->b = 0; // special alignment code
foo->g = 0; // normal access, but still unaligned
return 0;
}
The only safe way to do this is
int func(void) {
mystruct foo;
memcpy(&foo, getptr(), sizeof(mystruct));
...
which is done with DevicePath, but I'm not a compiler guru.
It's a huge pain to deal with and I too have no idea how often this shows
up in wild. Given that x86 ARM (only checked ARM11) allow misaligned
accesses it may not be worth the effort to realign everything. But I do
agree with you that most BIOSs probably don't enforce any alignment at all
but even in assembly:
mov $0x1, %eax
mov (%eax), %eax
is misaligned. I really dislike supporting things that break the spec, but
it does boil down to the customer experience. Again this is still just
confined to Itanium/EBC at the moment.
--Joe
On Sun, Jan 20, 2013 at 4:02 PM, David Woodhouse <dw...@infradead.org>wrote:
> 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
>
>
------------------------------------------------------------------------------
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
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
