On Fri, Jun 20, 2014 at 11:43:18AM +0200, Laszlo Ersek wrote: > On 06/20/14 10:55, Gary Ching-Pang Lin wrote: > > Hi Laszlo, > > > > On Wed, Jun 18, 2014 at 11:34:45PM +0200, Laszlo Ersek wrote: > >> This is a longish and quite raw email, but (for me at least) a big > >> improvement, so I'll share my findings here. > >> > > Thanks for your sharing. I followed the steps and saw the backtrace in gdb. > > This is exactly something I am longing for! > > > > What wasn't mentioned is the debug file path in > > BaseTools/Conf/tools_def.template > > needs a fix like this: > > > > - DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = > > --add-gnu-debuglink=$(DEBUG_DIR)\$(MODULE_NAME).debug > > + DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = > > --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug > > > > It took me a while to find out why the symbols were missing in GdbSyms.dll. > > Oh? I didn't realize that. > > I certainly have this patch in my local tree. (We tried to get it > upstream before but it didn't fly -- and in this context basetools can't > automatically substitute the platform-native path separator, so it'll > always be broken for one of the build platforms.) > Sounds bad :( I can live with the additional patch anyway.
> But if you omit this patch from the build, does it indeed cause > GdbSyms.dll to lack debug symbols? The above change only influences the > .gnu_debuglink section in the dll, and I'm unaware of any component in > this setup that would follow that link, from the .dll file to the .debug > file. > > Specifically, the python script (as far as I understand) only needs some > struct definitions from GdbSyms.dll, and those should be available > (embedded) directly in the dll, even without the link to the .debug file. > > Of course I could be wrong; I didn't try to analyze what happens without > debuglink. Perhaps the objcopy command fails if you use the wrong path > separator and then some *other* commands for the dll are not even > attempted? Hm. > I got this after reload-uefi if the patch wasn't applied. (gdb) reload-uefi -o Build/OvmfX64/DEBUG_GCC48/X64/DebugPkg/GdbSyms/GdbSyms/DEBUG/GdbSyms.dll Python Exception <class 'gdb.error'> No type named EFI_SYSTEM_TABLE_POINTER.: Error occurred in Python command: No type named EFI_SYSTEM_TABLE_POINTER. > > > > Besides, I had some strange error messages while executing "reload-uefi -o": > > > > add-symbol-file 8086100e.efidrv 0x68c82c0 > > add symbol table from file "8086100e.efidrv" at > > .text_addr = 0x68c82c0 > > Python Exception <class 'gdb.error'> 8086100e.efidrv: No such file or > > directory.: > > Error occurred in Python command: 8086100e.efidrv: No such file or > > directory. > > "8086100e.efidrv" is iPXE's UEFI driver for qemu's / Intel's e1000 NIC. > You have the driver in memory because qemu provides it in the NIC's pci > rom bar, and edk2 loads it from there. > Ok, thanks for the explanation. Gary Lin ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
