Hiya guys,
Sorry for being late. Duane had emailed me privately as well, but I just
hadn't gotten around to it all yet...
Anyway. Interesting about the .debug files. Something must have changed -
couple of years back during the first Xen GSoC it all worked fine with the
.dll files.
Feel free to send me any patches to apply. Wouldn't want to have a useful
tool bitrot.
Now - about looking at actual symbols. There's a different problem here.
GDB doesn't deal very well with EFI in that it doesn't deal well with
multiple modules with the same symbols. So the script is loading all the
symbols (for all modules in the module list anyway), but you won't be able
to look at the symbols you want all the time.
This is why I had developed module scope.
https://github.com/andreiw/andreiw-wip/blob/master/gdb/0001-GDB-Initial-prototype-of-symbol-file-scope-module-sc.patch
You can do stuff like:
Print &'DxeCore.dll'::gST
Never got around to going through the paper tape ("prove your stuff doesn't
break gdb") to merge this into mainline, but there it is. Should be
relatively simple to apply to a newer gdb code base. This shouldn't have
rotted too much in two years.
A
2013/4/10 Duane Voth <dua...@gmail.com>
> On Tue, Apr 9, 2013 at 10:20 PM, Joe Vernaci <jvern...@gmail.com> wrote:
>
> Thanks for making a new title it'll be easier to track...
>>
>> Andrew is right those have not changed in quite a long time and even if
>> they did since GdbSyms builds against current headers it won't matter.
>>
>>
>> Gcc builds the .dll files as a self contained binary which is passed
>> through GenFw which if needed will convert elf binaries to pe/coff (efi)
>> binaries. But the mingw cross compiler (UNIXGCC toolchain) is capable of
>> producing pe/coff on it's own for use in Windows. So to strip and preserve
>> the debug symbols in the gcc produced pe/coff .dll files objcopy is used to
>> place them in a .debug file and use .gnu_debuglink to point the .dll to
>> that file. GenFw then makes a it's own link from the .efi to the .dll.
>> The .gnu_debuglink probably isn't needed anymore but it was used when GenFw
>> wasn't as capable as it is now.
>>
>
> Ok so apparently I should have been loading .debug files instead of .dll
> files. :p The following (without recompiling anything) gets pretty far
> along:
>
> term1: $ qemu-system-x86_64 -m 1024 -bios OVMF.fd -S -s -monitor stdio
>
> term2: $ cd edk2/OvmfPkg
> term2: $ gdb
> term2: (gdb) target remote :1234
> term2: (gdb) c
> -- wait 5 seconds
> ctrl-c
> -- gdb complains several times about Remote 'g' packet reply is too long --
> term2: (gdb) set arch i386:x86-64
> term2: (gdb) source ../../andreiw-wip/uefi/DebugPkg/Scripts/gdb_uefi.py
> term2: (gdb) reload-uefi -o ../Build/AppPkg/DEBUG_GCC46/X64/GdbSyms.debug
> EFI_SYSTEM_TABLE @ 0x3fb59f18
> Connected to EDK II (Rev. 0x10000)
> ConfigurationTable @ 0x3fb58e18, 0x8 entries
> DebugImageInfoTable @ 0x3f980018, 0x39 entries
> Loading new symbols...
> add-symbol-file
> /home/duanev/efi/edk2/Build/OvmfX64/DEBUG_GCC46/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.debug
> 0x3fbcd260
> add symbol table from file
> "/home/duanev/efi/edk2/Build/OvmfX64/DEBUG_GCC46/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.debug"
> at
> .text_addr = 0x3fbcd260
> add-symbol-file
> /home/duanev/efi/edk2/Build/OvmfX64/DEBUG_GCC46/X64/MdeModulePkg/Universal/PCD/Dxe/Pcd/DEBUG/PcdDxe.debug
> 0x3fafc260
> ...
>
> So when I symbol-file load GdbSyms.debug instead of GdbSyms.dll,
> EFI_SYSTEM_TABLE_POINTER is fine.
>
> Now since in-memory values are used to compute load addresses, I have to
> let OVMF execute a ways before running reload-uefi. Fortunately my current
> problem is a hang, so I can simply ctrl-c gdb to make it stop in a useful
> place, and then run reload-uefi. Breakpoints don't work for me yet so this
> will have to do (besides breakpoints are going to be messy with the cpu
> mode switches and multiple memory maps).
>
> I also modded GdbSyms.py to load .debug files instead of .dlls, and now I
> can get all the way to:
>
> ...
> add-symbol-file
> /home/duanev/efi/edk2/Build/OvmfX64/DEBUG_GCC46/X64/OvmfPkg/QemuVideoDxe/QemuVideoDxe/DEBUG/QemuVideoDxe.debug
> 0x3e559260
> add symbol table from file
> "/home/duanev/efi/edk2/Build/OvmfX64/DEBUG_GCC46/X64/OvmfPkg/QemuVideoDxe/QemuVideoDxe/DEBUG/QemuVideoDxe.debug"
> at
> .text_addr = 0x3e559260
> add-symbol-file
> /home/jljusten/dev/edk2/Build/OvmfX64/RELEASE_GCC44/X64/OptionRomPkg/CirrusLogic5430Dxe/CirrusLogic5430Dxe/DEBUG/CirrusLogic5430Dxe.debug
> 0x3e552260
> add symbol table from file
> "/home/jljusten/dev/edk2/Build/OvmfX64/RELEASE_GCC44/X64/OptionRomPkg/CirrusLogic5430Dxe/CirrusLogic5430Dxe/DEBUG/CirrusLogic5430Dxe.debug"
> at
> .text_addr = 0x3e552260
> Python Exception <class 'gdb.error'>
> /home/jljusten/dev/edk2/Build/OvmfX64/RELEASE_GCC44/X64/OptionRomPkg/CirrusLogic5430Dxe/CirrusLogic5430Dxe/DEBUG/CirrusLogic5430Dxe.debug:
> No such file or directory.:
> (gdb)
>
> As I recall the Cirrus driver was recently turned off? For the moment
> I've explicitly skipped the load of the CirrusLogic symtable.
>
>
> Now I can do:
>
> (gdb) info address mDxeServices
> Symbol "mDxeServices" is static storage at address 0x315a0.
> (gdb) print mDxeServices
> $2 = {Hdr = {Signature = 0, Revision = 0, HeaderSize = 0, CRC32 = 0,
> Reserved = 0}, AddMemorySpace = 0x0,
> AllocateMemorySpace = 0x0, FreeMemorySpace = 0x0, RemoveMemorySpace =
> 0x0,
> GetMemorySpaceDescriptor = 0x0, SetMemorySpaceAttributes = 0x0,
> GetMemorySpaceMap = 0x0,
> AddIoSpace = 0x0, AllocateIoSpace = 0x0, FreeIoSpace = 0x0,
> RemoveIoSpace = 0x0,
> GetIoSpaceDescriptor = 0x0, GetIoSpaceMap = 0x0, Dispatch = 0x0,
> Schedule = 0x0, Trust = 0x0,
> ProcessFirmwareVolume = 0x0}
>
> Not all is good yet as obviously these values should not be zero...
> probably an initial offset problem.
>
> It also appears that only device driver symbols are being loaded - which
> makes sense as this is what Andrei was helping GsoC with. I'll need to get
> a few more modules loaded as there are no symbols yet for the area of code
> I'm trying to debug.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
--
A
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
