I’ve got a branch on a private repo (BZ3500-gdb @ https://github.com/ajfish/edk2.git <https://github.com/ajfish/edk2.git>) that has gdb and lldb scripts that can attach to QEMU and symbolicate EFI. These scripts also provide other useful commands (symbols, hob, guid, device path, system table) and pretty print (EFI_GUID, EFI_BOOT_MODE, EFI_STATUS, TPL, CHAR16)
I’d like to start a conversation on the best way to integrate this into the edk2. There is a debugger agnostic module that provides services abstracted by a Python file like object. You can run the efi_debugging.py directly and it will dump out section and debug info for EFI PE/COFF (TE) files, or import it into an lldb or gdb Python script (examples included in the branch). It should be possible to import these services into any debugger that supports Python scripting, and it should also be easy to import these services into existing Python debugging scripts. The efi_gdb.py and efi_lldb.py scripts assume a standard gdb remote stub and should work with QEMU, JTAG debugger, or EFI gdb serial stub. When using QEMU or JTAG it does not require any changes to EFI images to function. The only assumption about CPU architecture is that pointers are 32 or 64 bits. The 10,000 foot theory of operation is you attach with the debugger and walk the stack frame and symbolicate all the functions in the stack. From that if you get a symbol for gST you can find the debug info in the EFI System Table and load all the symbols. Example usage: Launch QEMU with the gdb stub: OvmfPkg/build.sh qemu -gdb tcp::9000 Attach with gdb and get a symbolicated backtrace: gdb -ex "target remote localhost:9000" -ex "source efi_gdb.py" -ex “efi" I’m happy to answer questions on the mailing list if folks want to kick the tires and try it out. Thanks, Andrew Fish PS The only feature I have not figured out is how to Pretty Print CHAR16 * the same way as char * in gdb. CHAR16 is printed properly, but you don’t get CHAR16 strings printed in gdb, like you do in lldb. I asked a question about this on the mailing list last week in case some one wants to look into it. That email had a test case that was a stand alone app and did not require OVMF to be running as it could be debugged my an OS command line C app. In case you have friends that are gdb experts, but don’t know much about EFI or EDK II. PPS Caveat Emptor… his is my 1st gdb Python script and I’m not the worlds best Python programmer…. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#77969): https://edk2.groups.io/g/devel/message/77969 Mute This Topic: https://groups.io/mt/84334474/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
