Andrew –
You are a UEFI expert with tons of background knowledge. Newer engineers see an
error like this and have no reasonable way to proceed. Try to dig up a FAQ on
this?
The EDK2 environment should support normal C operations for all data types
which are in the ABI. I can understand not supporting float intrinsics (floats
aren’t actually a part of the ABI, even if they can be used in a module) But
normal struct assignments, or UINT64 math?
Now x86 appears handicapped in comparison to ARM on EDK2. Why allow this to
persist?
Tim
From: Andrew Fish [mailto:[email protected]]
Sent: Monday, April 01, 2013 10:55 AM
To: [email protected]
Subject: Re: [edk2] x86 compiler intrinsics
Tim,
I think it is mostly struct operations that fail. So struct foo a, b. a = b or
a = 0
We decided at the beginning of edk2 to not support intrinsics to make it easier
to port to new compilers. EDK only supported a single compiler.
ARM came later. For math the code base target was IA32, so the math functions
in the BaseLib replace the need for compiler intrinsics. ARM has a much lower
bar for what operations require intrinsics and thus we decided to add the
intrinsics. So I tracked down intrinsics with the correct license.
IMHO it is more work to clean up for gcc/clang warnings than to find the
structure assignments.
Sent from my iPhone
On Apr 1, 2013, at 10:23 AM, Tim Lewis
<[email protected]<mailto:[email protected]>> wrote:
Mike –
Can we just move CompilerStubs back into the build? We already have
CompilerInstrinsics for ARM. What is preventing us from adding this and making
it easier for everybody.
In particular, we are moving modules from EDK-style to EDK2 style. They break.
Telling an engineer that they need to turn on assembly output to figure out
where it went wrong (when it was working in EDK) doesn’t seem like a good
solution.
Tim
From: Kinney, Michael D [mailto:[email protected]]
Sent: Monday, April 01, 2013 10:19 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] x86 compiler intrinsics
Tim,
When the compiler optimizations are turned up, the compiler may introduce these
calls, even then /Oi- is used. The resolution is to find the C code
statement(s) that are inducing this behavior and replace them with calls to the
BaseMemoryLib functions such as CopyMem(), SetMem(), and ZeroMem().
When the link time errors are observed for memcpy() and memset(), we usually
turn on mixed C/ASM output from the compiler and search for calls to the
intrinsic functions to identify the C code that needs to be updated.
Thanks,
Mike
From: Tim Lewis [mailto:[email protected]]
Sent: Monday, April 01, 2013 10:09 AM
To: [email protected]<mailto:[email protected]>
Subject: [edk2] x86 compiler intrinsics
Someone please refresh my memory: the MSVC toolchain generates intrinsic calls
to memcpy and memset. I don’t see /Oi- to disable them. I don’t see
CompilerStub being linked into native EDK2 modules. How are these being
resolved?
Tim
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
edk2-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
