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/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
