Follow edk2/CryptoPkg/Library/IntrinsicLib solution, I have fixed the link 
error for this driver. I will follow up to find a good solution to fix this 
link error.

Thanks,
Eric
From: Andrew Fish [mailto:af...@apple.com]
Sent: Saturday, June 20, 2015 3:05 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH v3] MdeModulePkg: Regular expression protocol


On Jun 19, 2015, at 10:25 AM, Doman, Jonathan 
<jonathan.do...@hp.com<mailto: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<mailto:af...@apple.com>]
Sent: Friday, June 19, 2015 11:38
To: edk2-devel@lists.sourceforge.net<mailto: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<mailto: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<mailto:eric.d...@intel.com>]
Sent: Friday, June 19, 2015 02:55
To: Tian, Feng; 
edk2-devel@lists.sourceforge.net<mailto: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<mailto:edk2-devel@lists.sourceforge.net>; 
jonathan.do...@hp.com<mailto: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<mailto: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<mailto:edk2-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to