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....@groups.io>
Sent: Monday, May 25, 2020 10:11 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; rebe...@bsdio.com
<rebe...@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 <rebe...@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&data=02%7C01%7Cawarkentin%40vmware.com%7C7dfa192f9f654d85b6a008d80122978c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637260595393730625&sdata=82w1tZV%2Bj0J1pdnWI7WU4OTmfW%2F1BOjm7BzvaCF8TZ4%3D&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&data=02%7C01%7Cawarkentin%40vmware.com%7C7dfa192f9f654d85b6a008d80122978c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637260595393730625&sdata=aU3uRBIWhjealofdqjDMHKSsi0d18Z7ZNN8DlZFo5uE%3D&reserved=0
Thanks,
Andrew Fish
>
> --
> Rebecca Cran
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#60239): https://edk2.groups.io/g/devel/message/60239
Mute This Topic: https://groups.io/mt/74450304/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
