Brian J. Johnson [mailto:[email protected]] wrote:
[...] ]> In this case, even the Microsoft Visual Studio debugger gives ]> the appearance of stepping through the 'wrong' function. But ]> the linker /verbose output confirms the debugger is correct: ]> ]> Selected symbol: ]> _f1 from 1.obj ]> Replaced symbol(s): ]> _f2 from 1.obj ]> _f3 from 1.obj ] ]FWIW I have seen this behavior most commonly with functions which, after ]optimization, simply return a constant (eg. TRUE, or EFI_SUCCESS.) It's ]a bit surprising when looking at symbol names, but it always seems to ]produce correct results. ]-- ] ] Brian That is my experience too. I see now that this optimization is called 'comdat folding' and is explained here: http://msdn.microsoft.com/en-us/library/bxwfs976.aspx Here are a few cases of comdat folding from a current EDK2 OVMF build using VS2010 tools: Selected symbol: PeiDefaultIoWrite16 from PeiCore.lib(CpuIo.obj) Replaced symbol(s): PeiDefaultIoWrite32 from PeiCore.lib(CpuIo.obj) PeiDefaultIoWrite64 from PeiCore.lib(CpuIo.obj) PeiDefaultIoWrite8 from PeiCore.lib(CpuIo.obj) PeiDefaultMemWrite16 from PeiCore.lib(CpuIo.obj) PeiDefaultMemWrite32 from PeiCore.lib(CpuIo.obj) PeiDefaultMemWrite64 from PeiCore.lib(CpuIo.obj) PeiDefaultMemWrite8 from PeiCore.lib(CpuIo.obj) Selected symbol: CoreEmptyCallbackFunction from DxeCore.lib(Dispatcher.obj) Replaced symbol(s): SzFree from LzmaDecompressLib.lib(LzmaDecompress.obj) Selected symbol: DxePcdSet8 from PcdDxe.lib(Pcd.obj) Replaced symbol(s): DxePcdSetBool from PcdDxe.lib(Pcd.obj) Here is a case where more complex functions are folded. The source code of the merged functions is quite different, but evidently the intermediate code is the same: Selected symbol: HexCharToUintn from UefiShellDebug1CommandsLib.lib(UefiShellDebug1CommandsLib.obj) Replaced symbol(s): InternalHexCharToUintn from BaseLib.lib(String.obj) Building OVMF using VS2010 results in 35 cases of comdat folding. I confirmed the optimization can be prevented replacing linker options " /OPT:REF /OPT:ICF=10" with "/NOICF". Avoiding the use of static functions is _not_ preventing the comdat folding optimization. So either the original problem was due to another cause, or more likely the removal of static functions did avoid comdat folding when a different compiler version and/or options was used. I think the decision to ban the use of static functions should be revisited. If the original debugger problem can be reproduced and confirmed to be due to comdat folding, then engineers can learn to recognize and appreciate comdat folding and understand that debugger behavior is correct. Alternatively, comdat folding could be disabled for the NOOPT build. If the original debugger problem is not due to comdat folding, then it should be documented along with steps to reproduce in case someone wants to investigate. Right now, the static function ban is not even mentioned in an EDK2 coding document. Banning a C language feature as mainstream as static functions should be avoided if possible, and carefully documented if not. Thanks, Scott ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
