On 02/03/14 23:02, Bill Paul wrote: > Since I'm building on FreeBSD, I'm using the generic UNIX instructions for > building with the EDK2. This means I'm using the cross-compiler tools > generated by the mingw-gcc-build.py script.
(BaseTools/gcc/README.txt seems to imply that the output of these scripts are not (regularly) tested on FreeBSD.) > For the most part this works fine, but I noticed that when I build OVMF, I > see > the following warnings: > > edk2/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c: In function > 'FvbGetPhysicalAddress': > edk2/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c:249: error: > 'FwhInstance' may be used uninitialized in this function > This appears to be due to lines like this: > > EFI_FW_VOL_INSTANCE *FwhInstance; > > which should be this: > > EFI_FW_VOL_INSTANCE *FwhInstance = NULL; > > This is easily corrected, but I'm wondering why nobody else seems to have > noticed it. Maybe newer versions of GCC ignore it? At least in FvbGetPhysicalAddress(), there's an ASSERT_EFI_ERROR(Status). Gcc's warning is incorrect (at least in DEBUG builds). I guess newer gcc versions might deduce that. > Maybe people are using > Windows? Yes. > Also, I also noticed a few glitches when trying to build the sample apps in > AppPkg. > > For example: > > edk2/StdLib/BsdSocketLib/ns_print.c: In function '__ns_sprintrrf': > edk2/StdLib/BsdSocketLib/ns_print.c:231: error: format '%Lu' expects type > 'long long unsigned int', but argument 3 has type 'u_long' > edk2/StdLib/BsdSocketLib/ns_print.c:519: error: format '%Lu' expects type > 'long long unsigned int', but argument 5 has type 'u_long' > > Apparently it wants the %Lu to be just %u Seems like a genuine bug (when built for Ia32). > > Similarly: > > edk2/StdLib/BsdSocketLib/res_debug.c: In function '__p_option': > edk2/StdLib/BsdSocketLib/res_debug.c:539: error: format '%Lx' expects type > 'long long unsigned int', but argument 3 has type 'u_long' > > %Lx should be %x > > Lastly, during the link phase, I get errors like this: > > edk2/Build/AppPkg/RELEASE_UNIXGCC/IA32/StdLib/EfiSocketLib/EfiSocketLib/OUTPUT/EfiSocketLib.lib(Init.obj):/home/wpaul/edk/edk2/StdLib/EfiSocketLib/Init.c:57: > > undefined reference to `mpfnEslConstructor' > > This is defined in StdLib/EfiSocketLib/UseEfiSocketLib.c along with a bunch > of > other globals as follows: > > PFN_ESL_xSTRUCTOR mpfnEslConstructor __attribute__((weak)) = > EslServiceNetworkConnect; ///< Constructor for EfiSocketLib > > The issue seems to be that when using the weak attribute, the compiler ends > up > producing objects with symbols like this: > > 00000000 D .weak._mpfnEslConstructor._EslServiceNetworkDisconnect > > The linker seems unable to resolve them because of the .weak prefix. I hacked > around this in my local tree by just getting rid of the __attribute__((weak)) > tag. The weak attribute comes from SVN r13475, but the commit message doesn't explain to me why the attribute was necessary. > It's possible that all of this may be attributable to the cross compiler > toolchain being out of date, but these seem like genuine bugs to me. Again, > I'm surprised they haven't been noticed before. You could be the first user ever to try to build these on FreeBSD, with the UNIXGCC toolset. Can you try with GCC44+ instead? (At least OvmfPkg/README has such a recommendation (from SVN r13569), albeit for completely different grounds.) The ports tree seems to have GCC46 even. Thanks Laszlo ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
