Re: [edk2-devel] OVMF gdb seems to require "stone knives and bearskins" to debug code?

["Andrei Warkentin" <awarkentin@vmware.com>]

[-- Attachment #1: Type: text/plain, Size: 4835 bytes --]

I may not have the full context here... actually, I'm sure I don't. I am incidentally the original author of the DebugPkg python script[1], but if I understood correctly, it was picked up by a number of different folks over the years and possibly evolved separately... I certainly don't remember anyone ever reaching back with improvements or anything else. Having proper debug scripts be part of edk2 would be nice (and I don't care who's scripts to be honest).

I last touched this about 5 years ago, where I fixed some bit rot. I'm almost positive I tried it with AArch64 at some point, and I even tried it with PPC64LE ("heh").

The whole business with the GdbSyms... it's just so the EFI structures are not hardcoded into the script itself (which makes it portable across different arches/bitness, for example). GdbSyms does *not* need to be part of your EFI FD and is not actually executable.

The script follows the UEFI spec to locate the EFI ST and the debug directory or w/e that thing was to get at all the loaded images in the system. It works like magic. Now GDB had another problem that made UEFI debugging painful - it doesn't really deal well with multiple unrelated modules occupying the same address space and having same symbol names in multiple places. See https://github.com/andreiw/andreiw-wip/blob/master/gdb/0001-GDB-Initial-prototype-of-symbol-file-scope-module-sc.patch for the other thing you'll need to make UEFI debugging a reality.

[ this is not upstreamed and might not even apply anymore...gdb process for merging changes was quite bureaucratic and I never had the time to embark on all the yak shaving activities I was asked to do ]

[1] https://github.com/andreiw/andreiw-wip/blob/master/uefi/DebugPkg/Scripts/gdb_uefi.py
________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Andrew Fish via groups.io <afish=apple.com@groups.io>
Sent: Monday, May 25, 2020 10:11 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; rebecca@bsdio.com <rebecca@bsdio.com>
Subject: Re: [edk2-devel] OVMF gdb seems to require "stone knives and bearskins" to debug code?



> On May 25, 2020, at 7:19 PM, Rebecca Cran <rebecca@bsdio.com> wrote:
>
> On 5/24/20 9:30 PM, Andrew Fish via groups.io wrote:
>
>> I could open source an lldb symbolication Python script and I'm happy to explain the common logic to some one to make it easier to port this  lldb command [3] to gdb. The command can load symbols for any address that is located in a loaded PE/COFF image, and when you import the command into lldb it symbolicates the current frame.
>
>
> As Laszlo has already explained, information about debugging with gdb is a bit scattered. I seem to recall there were discussion about getting the DebugPkg into edk2, but there was disagreement about it.
>
> However, since I work on platforms which have lldb in base (FreeBSD) or are easily available (Linux), I'd certainly be interested if you were to open source the efi_symolicate.py script and I could learn how to use lldb.
>

Rebecca,

Thanks for the feedback, and the help over the years.  When I get my other Xcode commits upstreamed I can commit the  lldb script if we can agree as a community the location of that new content. I've already refactored the lldb script to use a class to abstract lldb specifics, so that should make it much easier to port to gdb.

FYI the magic to get lldb working with QEMU is:
$ curl -O https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fllvm-mirror%2Flldb%2Fmaster%2Fexamples%2Fpython%2Fx86_64_target_definition.py&amp;data=02%7C01%7Cawarkentin%40vmware.com%7C7dfa192f9f654d85b6a008d80122978c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637260595393730625&amp;sdata=82w1tZV%2Bj0J1pdnWI7WU4OTmfW%2F1BOjm7BzvaCF8TZ4%3D&amp;reserved=0
$ lldb -o "settings set plugin.process.gdb-remote.target-definition-file x86_64_target_definition.py" -o "gdb-remote 1234"   -o "command script import efi_symbolicate.py"

The issue is the lldb gdb-remote does not fall back to a primitive serial protocol so we need to point it at  x86_64_target_definition.py to know how to connect. This also gets rid of he need to point at an executable. If you remove importing my script that will give you assembly level debugging with QEMU. But source is more interesting, unless you are really stuck.

This is a good place to start to learn lldb: https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flldb.llvm.org%2Fuse%2Fmap.html&amp;data=02%7C01%7Cawarkentin%40vmware.com%7C7dfa192f9f654d85b6a008d80122978c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637260595393730625&amp;sdata=aU3uRBIWhjealofdqjDMHKSsi0d18Z7ZNN8DlZFo5uE%3D&amp;reserved=0

Thanks,

Andrew Fish

>
> --
> Rebecca Cran
>
>
>
>
>





[-- Attachment #2: Type: text/html, Size: 7987 bytes --]