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
