Thanks Eric for the help! How do you want to handle this? Are you going to
submit a new combined patch with the fixes?
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, June 29, 2015 9:04 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH v3] MdeModulePkg: Regular expression protocol
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<mailto: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
