> On Jun 19, 2015, at 10:25 AM, Doman, Jonathan <jonathan.do...@hp.com> wrote: > > Thanks for the info Andrew. I was able to track down a memset intrinsic call > that was replacing a for loop that initialized a block of memory to a > constant value. Other instances may be large assignments as you suggest. > However, this is in third-party code that I would prefer to modify as little > as possible. > > I'm under the impression that compiler intrinsics are not allowed in EDK2. Do > I have to tweak the third party code so that intrinsic patterns are no longer > recognized?
The edk2 code that is part of the Porting glue can implement it. This is an example. https://svn.code.sf.net/p/edk2/code/trunk/edk2/CryptoPkg/Library/IntrinsicLib/CopyMem.c /* Copies bytes between buffers */ void * memcpy (void *dest, const void *src, unsigned int count) { return CopyMem (dest, src, (UINTN)count); } Pedantically speaking it is not correct as count is size_t and it is not always true that sizeof (int) == sizeof (size_t). void *memcpy(void *restrict s1, const void *restrict s2, size_t n); For example I use clang (Xcode) and size_t is an unsigned long. For you VC++ uses please don’t get confused as long is 4 bytes on VC++, but 4 (i386) or 8 (x86_64) bytes on most other compilers. But this is a good example of why UEFI/edk2 has defined a type system that is portable among the supported compilers. If you start using generic types, portability can be broken. I’ve had some painful times tracking down bugs in vendor code where they use long and made the code non portable…. The problem here is the compiler has a priori knowledge about sizeof(size_t) and that is how the compiler will generate code to call memcpy(). Thus it could be passing 64-bits of data, but this C code above has a 32-bit argument, it at least converts the 32-bits to 64-bits when needed for the CompMem() call. But it is kind of just dumb luck that this seems to work. For example if count was passed on the stack as 64-bits, and it was not the last argument things would get really messed up. Note: It is likely that size_t maps to UINTN assuming all the compilers support “large” objects in their 64-bit flavors. Thanks, Andrew Fish > ________________________________________ > From: Andrew Fish [af...@apple.com] > Sent: Friday, June 19, 2015 11:38 > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] [PATCH v3] MdeModulePkg: Regular expression protocol > >> On Jun 19, 2015, at 8:31 AM, Doman, Jonathan <jonathan.do...@hp.com> wrote: >> >> Hi Eric, >> >> I had a lot of trouble with intrinsics (although now both GCC49 and VS2013 >> work for me). When compiling the regex library, MSVC inserts calls to >> intrinsics where no function call exists. /Oi- didn't fix this, so I decided >> to redefine memcpy/set by copying definitions from CryptoPkg/IntrinsicLib. I >> can't reproduce your error, but do you have a suggestion for how to fix >> this? I don't understand what MSVC is doing. >> > > The code is probably violating the edk2 coding standard and doing a = with > data that is bigger than a UINTN at execution time. This can cause the > compiler to emit intrinsics, like memcpy. General what can happen is the > compilers optimizer may chose to optimize out the memcpy for smaller > assignments and the code may look like it will work. What you tend to see is > the code will fail to link when you compile with optimizations disabled, as > the optimizer tends to randomly hide the intrinsics. > > So for example globals work fine as they are done at compile time, so the > data ends up in the PE/COFF image. > > UINTN gInit[] = { 1, 2, 3, 4 }; > > But if you do the same thing in a function. > > UINTN Init[] = { 1, 2, 3, 4 }; > > It causes code to be generated that runs every time the function is called. > Since = is > sizeof (UINTN) it is legal for the compiler to emit the memcpy > intrinsic. > > The same issue exists with using = with a structure. The code needs to use > CopyMem(), and not = in these cases. > > Thanks, > > Andrew Fish > > PS if you are using VS2013 you can use the /FAcs compiler flag to generate a > .cod file. You can search for the memcpy in the .cod file and track down the > C code that is causing the issue. > >> ________________________________________ >> From: Dong, Eric [eric.d...@intel.com] >> Sent: Friday, June 19, 2015 02:55 >> To: Tian, Feng; edk2-devel@lists.sourceforge.net; Doman, Jonathan >> Subject: RE: [PATCH v3] MdeModulePkg: Regular expression protocol >> >> Jonathan, >> >> I merged the code and build with VS2013(build -t VS2013x86 -p >> MdeModulePkg\MdeModulePkg.dsc -a X64), but it failed with below error >> message, can you help to fix the build errors? >> Finished generating code >> RegularExpressionDxe.lib(unicode.obj) : fatal error LNK1237: during code >> generation, compiler introduced reference to symbol memcpy defined in module >> 'RegularExpressionDxe.lib(OnigurumaIntrinsics.obj)' compiled with /GL >> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual >> Studio 12.0\Vc\bin\x86_amd64\link.exe"' : return code '0x4d5' >> Stop. >> >> Thanks, >> Eric >> -----Original Message----- >> From: Tian, Feng >> Sent: Friday, June 19, 2015 9:55 AM >> To: edk2-devel@lists.sourceforge.net; jonathan.do...@hp.com; Dong, Eric >> Cc: Tian, Feng >> Subject: RE: [PATCH v3] MdeModulePkg: Regular expression protocol >> >> Thanks for your contribution, Jonathan. >> >> Eric would review this patch and get back to you if he has feedback >> >> Thanks >> Feng >> >> -----Original Message----- >> From: Doman, Jonathan [mailto:jonathan.do...@hp.com] >> Sent: Friday, June 19, 2015 02:23 >> To: edk2-devel@lists.sourceforge.net >> Subject: [edk2] [PATCH v3] MdeModulePkg: Regular expression protocol >> >> Patch is hosted on github here: >> >> https://github.com/jrmrjnck/edk2/commit/b186f03121679b44cc224d7c69f04f9b4b799bc3.patch >> >> Unfortunately, the patch is too large and gets stuck in the edk2-devel mod >> queue. >> The bulk of it is a new regular expression library, so it doesn't make sense >> to split up. >> Please let me know if there is a preferred way to submit large patches. >> >> >> Add driver to produce EFI_REGULAR_EXPRESSION_PROTOCOL. Based on Oniguruma >> v5.9.6 (BSD 2-clause license), which provides full Unicode support, and >> POSIX ERE and Perl regex syntaxes. >> --- >> v3 changes: >> * Put regex library directly under driver and forget about driver/library >> de-coupling. >> * Switch from SLRE to Oniguruma implementation, which is much more robust >> and useful. >> ------------------------------------------------------------------------------ >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/edk2-devel >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
