Tim,
So I've hit this issue too. There was a bug Xcode a while back in regards to
correctly following the alignment rules for EFI. The compiler was placing
16-bit Unicode strings on odd boundaries. I filed a bug and the compiler has
since been fixed.
I think the best solution may be to to have a PCD feature flag to control this
feature. If you are constructing code in the edk2 you mostly want it to be
generic and we can default to turning it on. If you are construction code with
looser rules you can turn it off.
Thanks,
Andrew
On Feb 13, 2013, at 4:33 PM, Tim Lewis <[email protected]> wrote:
> Mike –
>
> 1) I didn’t suggest a different BaseLib for each CPU architecture.
> Rather, on those architectures that have alignment issues, the specific
> functions with those issues be broken out into the CPU architecture specific
> directory, as we do in BaseLib already.
> 2) Actually, the UEFI specification is unclear on this point since it
> says: “Unless otherwise specified all data types are naturally aligned.” This
> is not stated as a requirement. It is stated as a fact. The language is
> almost identical to that used by compiler vendors to describe their behavior
> in placing variables and struct members. However, they does not translate
> into a prescriptive requirement. The only place where alignment is mentioned
> in the specification otherwise is in dealing with device paths.
Well the practicality of it is you need the EFI C ABI to follow the alignment
rules spelled out in the spec. So for example with clang we have to use
-mms-bitfileds for IA32 to get a UINT64 to start on a natural boundary. For
Linux/OS X ABIs a UINT64 will start on a UINT32 boundary. This implies how the
compiler should align strings that are just data.
> 3) Most of the code written using EDK II is not intended for all CPU
> architectures. Moving the design requirement of the EDK II onto the caller of
> the EDK II seems an undue burden.
I agree, but the code in the edk2 should try to be as alignment clean as
possible.
> 4) The rule is not implemented consistently: StrCmp does not have it but
> StrCpy and StrLen do.
> 5) Since wchar_t does not have the restriction you mentioned, the StdLib
> should not be using BaseLib for these functions, since they are not
> semantically identical.
I agree given the current behavior this is a bug in the StdLib.
> 6) An ASSERT is useful only on a system where the issue is a critical
> error.
So I totally disagree as the purpose of the ASSERT is to help write code that
is correct.
Please see:
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670
> Causing a hang, even on a debug build, on a system where it is known in-fact,
> not to cause an error just causes unnecessary debug time and product delays.
> This is not theoretical. Three weeks ago, we ran into the exact same error as
> Sathya, for a specific OEM motherboard. Could we have allocated a second
> aligned string, copied the first into it and then compared it? Wait, how can
> I copy the string or get its length? I have to construct a custom string
> length and copy routing using ReadUnaligned16()???
> 7) Possible solutions to preserve ASSERTs in the correct cases? ASSERTs
> which are architecture-specific can use EDK II symbols (i.e. MDE_CPU_IPF) to
> catch the issues on the architecture.
As I mentioned my preference would be a PCD feature flag. As I like the option
of trying to keep code as generic as possible. We did a lot of the initial ARM
work with alignment faults turned on, so it was nice that the edk2 code was
alignment safe.
> Also, many compiler chains (VC++ and GCC 4.7) support an unaligned modifier
> on pointers which forces the compiler to generate byte-access code.
>
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
