[edk2-devel] Gdb and lldb support for OVMF and more

[Rebecca Cran]

Could you commit the fixes I submitted to EmulatorPkg/Unix/lldbefi.py 
too, please?

See "[edk2-devel] [PATCH] EmulatorPkg: Update lldbefi.py to work with 
current lldb which uses python3"


Also, could you take another look at the updated Xcode wiki instructions 
I provided in "[edk2-devel] [tianocore.github.io.wiki PATCH 1/1] 
Xcode.md: Update instructions to work on modern macOS and Xcode 
versions" please? If you don't have time to verify them, perhaps they 
could be committed anyway since they're likely more accurate than the 
existing outdated page?


Thanks.

Rebecca Cran


On 7/20/21 9:08 AM, Andrew Fish via groups.io wrote:
> 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 (#77985): https://edk2.groups.io/g/devel/message/77985
Mute This Topic: https://groups.io/mt/84334474/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20210720/d0f1d9f5/attachment.htm>