The BaseLib.h has unaligned read and write functions to help with alignment
issues.
On ARMv7 (like the BeagleBoard) it is possible turn on and off the alignment
exceptions. So it it possible to test the code for alignment faults if needed.
Andrew Fish
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdePkg/Include/Library/BaseLib.h
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/BeagleBoardPkg/Sec/Arm/ModuleEntryPoint.S
On Jan 21, 2013, at 10:13 AM, Joe Vernaci <jvern...@gmail.com> wrote:
> Ah I see, that is good to know and handy in the right situation. But yes I
> see how that could be abused. I guess your suggestions for the lax alignment
> does make sense for better support. Maybe just throw in a warning message
> about breaking the pci spec and call it a day.
>
>
> On Sun, Jan 20, 2013 at 7:11 PM, David Woodhouse <dw...@infradead.org> wrote:
> On Sun, 2013-01-20 at 18:39 -0500, Joe Vernaci wrote:
> > AFAIK the __attribute__((packed)) only allows for unaligned member
> > accesses but assumes the root of the structure will be aligned.
>
> I have often wished that that were true (or at least for GCC to have a
> 'nopadding' attribute for which is *is* true), but unfortunately it's
> not:
>
> struct foo1 { int a; } __attribute__((packed));
> int retfoo1 (struct foo1 *p) { return p->a; }
>
> struct foo2 { int a; };
> int retfoo2 (struct foo2 *p) { return p->a; }
>
> [dwmw2@shinybook ~]$ arm-linux-gnu-gcc -O2 -c foo.c ; arm-linux-gnu-objdump
> -d foo.o
>
> foo.o: file format elf32-littlearm
>
>
> Disassembly of section .text:
>
> 00000000 <retfoo1>:
> 0: e5d03000 ldrb r3, [r0]
> 4: e5d01001 ldrb r1, [r0, #1]
> 8: e5d02002 ldrb r2, [r0, #2]
> c: e1833401 orr r3, r3, r1, lsl #8
> 10: e5d00003 ldrb r0, [r0, #3]
> 14: e1833802 orr r3, r3, r2, lsl #16
> 18: e1830c00 orr r0, r3, r0, lsl #24
> 1c: e12fff1e bx lr
>
> 00000020 <retfoo2>:
> 20: e5900000 ldr r0, [r0]
> 24: e12fff1e bx lr
>
>
> It's a pain, because people like to litter their structure definitions
> with __attribute__((packed)) just in *case* the compiler randomly
> decides to put padding into a structure which wouldn't naturally get it
> anyway. And this has a massively detrimental effect on performance for
> some targets. If we had __attribute__((nopadding)) that worked as you
> suggest (although you had four bytes between your ints in your example
> when I think you meant to have three), that would be very useful.
>
> But no, __attribute__((packed)) does do exactly what I intended it to do
> in *this* case. Except that it isn't portable to other toolchains, I
> suspect.
>
> --
> 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. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
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. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
