Gary Ching-Pang Lin [mailto:g...@suse.com] wrote:
<...> ]> > It turned out the problem is caused by VfrCompile + glibc 2.18. ]> > I built the programs in BaseTools/Source/C static-linked with glibc 2.17 ]> > and replaced the binaries in BaseTools/Source/C/bin, and the OVMF image that ]> > is built with static-linked VfrCompile showed the secure boot menu as ]> > expected. So, either the glibc commit is buggy, or some black magic in new ]> > gcc/glibc causes the problem. Isn't vfrcompile an ordinary application? If it is, that rules out a problem related to any unique requirements of the EDK2 environment. It seems unlikely that a released glibc memcpy is buggy. Is it possible that the memcpy() in VfrFormPkg.cpp should have been memmove() all along? If the buffers overlap, memcpy may or may not work, depending on the implementation. Maybe glibc 2.17=>2.18 changed the memcpy implementation such that an incorrect memcpy call is now exposed. It is at least worth verifying no buffer overlap before filing a bug report against glibc memcpy. Thanks, Scott <...> ] ]Thanks, ] ]Gary Lin ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
