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.
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.
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.
6) An ASSERT is useful only on a system where the issue is a critical
error. 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. Also, many compiler chains (VC++ and GCC
4.7) support an unaligned modifier on pointers which forces the compiler to
generate byte-access code.
Tim
From: Kinney, Michael D [mailto:[email protected]]
Sent: Wednesday, February 13, 2013 10:42 AM
To: [email protected]
Subject: Re: [edk2] How to align auto variables?
Tim,
Of course we could have different versions of the BaseLib for each CPU
architecture. But that does not address the potential incompatibilities that
may be introduced in the C code that calls the functions in the BaseLib.
Much of the C source code in the EDK II project is intended to be compatible
with all CPU architectures supported by the UEFI Specification. We want to
catch C code that introduces incompatibilities as early as possible. The best
place to catch these are at build time if at all possible. If it is a
condition that cannot be caught at build time, then the next best place is an
ASSERT() in a DEBUG build.
Please let me know if you have ideas on how to move this from an ASSERT() to a
build failure for all conditions.
Thanks,
Mike
From: Tim Lewis [mailto:[email protected]]
Sent: Wednesday, February 13, 2013 10:27 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] How to align auto variables?
An ASSERT is just another word for a hang. Every architecture that does not
have this issue hangs because one architecture does have this issue? In some
conditions, when the alignment fault code hasn't been loaded yet?
That is what APIs are for: to abstract those differences. There are means built
into EDK2 for supporting such architectural difference (the Ipf directory
springs to mind), right?
Most engineers assume that StrCmp and wcscmp are semantically identical and
that CHAR16 is the same as wchar_t.
Tim
From: Kinney, Michael D [mailto:[email protected]]
Sent: Wednesday, February 13, 2013 10:20 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] How to align auto variables?
Tim,
There are CPU architectures supported by the UEFI Specification that will
generate an alignment fault if there is an unaligned access.
Mike
From: Tim Lewis [mailto:[email protected]]
Sent: Wednesday, February 13, 2013 10:16 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] How to align auto variables?
Mike -
Why is the library enforcing this? An ASSERT is used for a critical runtime
error where a function cannot proceed. This condition does not fall into this
category on any platform that I am aware of (although there might be a speed
penalty).
Tim
From: Kinney, Michael D [mailto:[email protected]]
Sent: Wednesday, February 13, 2013 9:37 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] How to align auto variables?
Sathya,
Those ASSERT() statements in APIs that operate in Unicode strings with a
character type of CHAR16.
Is your string declared as a CHAR16 array? If it is, then the compiler should
align in 16-bot boundary automatically. The one exception is an CHAR16 array
in a packed structure. If you are using a packed structure, then you need to
order the fields or add padding fields as required to force proper alignment of
individual fields.
If you are using pointer math to compute a CHAR16 * into a buffer, then you are
responsible for alignment if the buffer data is not aligned. You may need to
copy contents of the buffer to a different buffer that is aligned.
Best regards,
Mike
From: Prakash, Sathya [mailto:[email protected]]
Sent: Wednesday, February 13, 2013 9:19 AM
To: [email protected]<mailto:[email protected]>
Subject: [edk2] How to align auto variables?
I am able to compile my code successfully with UDK but when I run my code I see
lot ASSERTS similar to ASSERT (((UINTN) String & BIT0) == 0);
I have used a static library in my code which is compiled in EDK1.6 (I need to
port that to UDK but for now I am keeping this way to do some basic testing)
I would like to know how to tell the compiler to align the char array allocated
in string to be aligned to avoid the ASSERT? Do I need to use
__declspec(align(#)) across all the variable definitions, can I pass it once as
a compile flag?
Thanks
Sathya
------------------------------------------------------------------------------
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
