On Jul 25, 2012, at 5:03 AM, Ni, Ruiyu wrote: > Andrew, > I found EmulatorPkg is using <Module>.dll as the debug symbol by sourcing > Build/Emulator/DEBUG_GCC46/X64/Host.gdb as the GDB script. Actually > <Module>.debug should be used. Because Conf/build_rule.txt strips the debug > information out of the <ModuleName>.dll and creates a separate debug symbol > file <Module>.debug to store all the .debug_xxx sections. > > So I think we may need to change the EmulatorPkg/Unix/Host/Host.c to generate > the correct Host.gdb by using <Module>.debug. >
If you look at https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EmulatorPkg/Unix/Host/Host.c GdbScriptAddImage(). You will see that gdb script file just uses the PdbPointer, which maps to the file name in the debug section of the PE/COFF image. For Xcode/clang we convert the Mach-O file (*.dll) to PE/COFF with a tool called mtoc (Mach-O to Coff). This tool places <ModuleName>.dll in the PE/COFF debug section, which is correct in this case. The Mach-O image (*.dll) contains all the debug info, and this info is not moved over to the PE/COFF image. DEBUG_XCODE32_*_MTOC_FLAGS = -align 0x20 -d $(DEBUG_DIR)/$(MODULE_NAME).dll RELEASE_XCODE32_*_MTOC_FLAGS = -align 0x20 Visual Studio places the <ModuleName>.pdb file name in the PE/COFF debug section. So it seems like your toolchain should place the <ModuleName>.debug file name in the PE/COFF debug section? > Another issue I observed only happens in Fedora. Even I changed Host.c to use > <Module>.debug as the symbol file. I still find the output of GDB "bt" > command cannot display the parameter value correctly. The output of GDB looks > like this: > ... > #17 0x0000000044f616a8 in PlatformBdsEnterFrontPage (TimeoutDefault=can't > compute CFA for this frame) > At > /home/ray/work/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c:1117 > #18 0x0000000043d786da in PlatformBdsPolicyBehavior (DriverOptionList=can't > compute CFA for this frame) > At > /home/ray/work/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsPlatform.c:413 > ... > > I found it's due to the missing of .eh_frame section which is removed by ld > because of the --gc-sections flag. If I remove the --gc-sections flag and > modify the Conf/build_rule.txt to keep .eh_frame section, the issue was gone. > <Command.GCC> > $(OBJCOPY) -only-keep-debug $(src) $(DEBUG_DIR)(+)$(MODULE_NAME).debug > $(OBJCOPY) --strip-unneeded $(src) > to > <Command.GCC> > $(CP) ${src} $(DEBUG_DIR)(+)$(MODULE_NAME).debug > $(OBJCOPY) --strip-unneeded $(src) > > But I don't think what the root cause is. Do you have any suggestion on this? > It looks like ELF x86_64 ABI defines .eh_frame for stack unwind. So it seems like that section is required in your debug info, but not in your final PE/COFF image? http://www.x86-64.org/documentation/abi.pdf 3.7 Stack Unwind Algorithm The stack frames are not self descriptive and where stack unwinding is desirable (such as for exception handling) additional unwind information needs to be gen- erated. The information is stored in an allocatable section .eh_frame whose format is identical to .debug_frame defined by the DWARF debug informa- tion standard, see DWARF Debugging Information Format, with the following extensions: > Regards, > Ray > > <winmail.dat> ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
