OVMF gdb seems to require "stone knives and bearskins" to debug code?

OVMF gdb seems to require "stone knives and bearskins" to debug code?

[Andrew Fish]

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

The full Star Trek quote from Spock is:  " I am endeavoring, ma'am, to construct a mnemonic memory circuit using stone knives and bearskins.", but I ran across this [1], and it felt like "stone knives and bearskins." vs my experience with lldb debugging EFI. 

So a few questions:
1) Is this Wiki [1]  actually up to date? 
2) Do we have a location to add debugger scripts to the edk2? If not what location should we chose?
3) Is anyone interested in writing gdb scripts to do better?

I've got no clue about writing gdb Python and I don't even have gdb installed on my system, but due to an accident of history I ended up owning my teams lldb Python debugger scripts so I know how lldb works in great detail. My expectation would be you have a standard way to to invoke the debugger and you get a symbolicated stack frame for free [2]. 

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. 

[1] https://github.com/tianocore/tianocore.github.io/wiki/How-to-debug-OVMF-with-QEMU-using-GDB 

[2] OVMF lldb attach:  $ lldb -o "settings set plugin.process.gdb-remote.target-definition-file x86_64_target_definition.py" -o "gdb-remote 9000" -o "command script import efi_symbolicate.py"
...

The "efi_symbols" command has been installed, type "help efi_symbols" for detailed help.
.......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Symbols Loaded for mach-O UUID 0AEF5192-F2D6-32D6-B739-54752B2D6B42 @ 0xfffcc094 /Volumes/Case/edk2-github/Build/OvmfX64/DEBUG_XCODE5/X64/OvmfPkg/Sec/SecMain/DEBUG/SecMain.dll
Symbols Loaded for mach-O UUID 7686209C-91AF-3D52-952C-BB2068CA682E @ 0x64e3000 /Volumes/Case/edk2-github/Build/OvmfX64/DEBUG_XCODE5/X64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll
Symbols Loaded for mach-O UUID FE5F915E-F2BF-3E7A-AE4D-7722043096CA @ 0x7eac000 /Volumes/Case/edk2-github/Build/OvmfX64/DEBUG_XCODE5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
PE/COFF Image not found. Can not load EFI Symbols
Symbols Loaded for mach-O UUID 86957245-00DA-3D0A-8060-295EAEB4A336 @ 0x7087000 /Volumes/Case/edk2-github/Build/OvmfX64/DEBUG_XCODE5/X64/MdeModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll
Symbols already loaded for mach-O UUID FE5F915E-F2BF-3E7A-AE4D-7722043096CA DxeCore
PE/COFF Image not found. Can not load EFI Symbols
Symbols already loaded for mach-O UUID FE5F915E-F2BF-3E7A-AE4D-7722043096CA DxeCore
PE/COFF Image not found. Can not load EFI Symbols
Symbols already loaded for mach-O UUID 7686209C-91AF-3D52-952C-BB2068CA682E Shell
Symbols Loaded for mach-O UUID 8000874A-80F4-37E3-9702-CB9A686F2260 @ 0x7167000 /Volumes/Case/edk2-github/Build/OvmfX64/DEBUG_XCODE5/X64/UefiCpuPkg/CpuDxe/CpuDxe/DEBUG/CpuDxe.dll
Symbols Loaded for mach-O UUID 89AB51B5-EB01-32B0-AA0A-5113E9882A82 @ 0x7ee3000 /Volumes/Case/edk2-github/Build/OvmfX64/DEBUG_XCODE5/X64/MdeModulePkg/Core/DxeIplPeim/DxeIpl/DEBUG/DxeIpl.dll
PE/COFF Image not found. Can not load EFI Symbols
Symbols already loaded for mach-O UUID 86957245-00DA-3D0A-8060-295EAEB4A336 BdsDxe
Symbols already loaded for mach-O UUID FE5F915E-F2BF-3E7A-AE4D-7722043096CA DxeCore
Symbols already loaded for mach-O UUID 89AB51B5-EB01-32B0-AA0A-5113E9882A82 DxeIpl
Symbols already loaded for mach-O UUID 0AEF5192-F2D6-32D6-B739-54752B2D6B42 SecMain
Symbols already loaded for mach-O UUID FE5F915E-F2BF-3E7A-AE4D-7722043096CA DxeCore
Symbols Loaded for mach-O UUID 5FDE6480-128B-3D18-9901-391924F9E54E @ 0x7ee8000 /Volumes/Case/edk2-github/Build/OvmfX64/DEBUG_XCODE5/X64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll
PE/COFF Image not found. Can not load EFI Symbols
Symbols already loaded for mach-O UUID FE5F915E-F2BF-3E7A-AE4D-7722043096CA DxeCore
Symbols already loaded for mach-O UUID 7686209C-91AF-3D52-952C-BB2068CA682E Shell
Symbols already loaded for mach-O UUID 0AEF5192-F2D6-32D6-B739-54752B2D6B42 SecMain
Symbols already loaded for mach-O UUID 89AB51B5-EB01-32B0-AA0A-5113E9882A82 DxeIpl
Symbols already loaded for mach-O UUID 86957245-00DA-3D0A-8060-295EAEB4A336 BdsDxe
Symbols already loaded for mach-O UUID 7686209C-91AF-3D52-952C-BB2068CA682E Shell
Symbols already loaded for mach-O UUID FE5F915E-F2BF-3E7A-AE4D-7722043096CA DxeCore
Symbols already loaded for mach-O UUID FE5F915E-F2BF-3E7A-AE4D-7722043096CA DxeCore
(lldb) bt
* thread #1, stop reason = signal SIGTRAP
  * #0: 0x000000000716796f CpuDxe.dll`CpuSleep + 1
    #1: 0x0000000007ebae33 DxeCore.dll`CoreRestoreTpl [inlined] CoreDispatchEventNotifies(Priority=<unavailable>) + 192 at /Volumes/Case/edk2-github/MdeModulePkg/Core/Dxe/Event/Event.c:194
    #2: 0x0000000007ebad73 DxeCore.dll`CoreRestoreTpl(NewTpl=4) + 290 at /Volumes/Case/edk2-github/MdeModulePkg/Core/Dxe/Event/Tpl.c:131
    #3: 0x0000000007ebb5f5 DxeCore.dll`CoreSignalEvent(UserEvent=<unavailable>) + 111 at /Volumes/Case/edk2-github/MdeModulePkg/Core/Dxe/Event/Event.c:566
    #4: 0x0000000007ebb71b DxeCore.dll`CoreWaitForEvent(NumberOfEvents=1, UserEvents=0x0000000007016f08, UserIndex=0x0000000007eab840) + 94 at /Volumes/Case/edk2-github/MdeModulePkg/Core/Dxe/Event/Event.c:707
    #5: 0x00000000064ebf0e Shell.dll`FileInterfaceStdInRead(This=<unavailable>, BufferSize=0x0000000007eab998, Buffer=<unavailable>) + 310 at /Volumes/Case/edk2-github/ShellPkg/Application/Shell/FileHandleWrappers.c:532
    #6: 0x00000000065071ce Shell.dll`_ModuleEntryPoint [inlined] DoShellPrompt + 267 at /Volumes/Case/edk2-github/ShellPkg/Application/Shell/Shell.c:1346
    #7: 0x00000000065070c3 Shell.dll`_ModuleEntryPoint [inlined] UefiMain(ImageHandle=<unavailable>, SystemTable=<unavailable>) + 5536 at /Volumes/Case/edk2-github/ShellPkg/Application/Shell/Shell.c:621
    #8: 0x0000000006505b23 Shell.dll`_ModuleEntryPoint [inlined] ProcessModuleEntryPointList(ImageHandle=<unavailable>, SystemTable=<unavailable>) at /Volumes/Case/edk2-github/Build/OvmfX64/DEBUG_XCODE5/X64/ShellPkg/Application/Shell/Shell/DEBUG/AutoGen.c:1000
    #9: 0x0000000006505b23 Shell.dll`_ModuleEntryPoint(ImageHandle=0x0000000006d1bf18, SystemTable=<unavailable>) + 8668 at /Volumes/Case/edk2-github/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
    #10: 0x0000000007eb08e7 DxeCore.dll`CoreStartImage(ImageHandle=0x0000000006d1bf18, ExitDataSize=0x00000000067987f0, ExitData=0x00000000067987e8) + 311 at /Volumes/Case/edk2-github/MdeModulePkg/Core/Dxe/Image/Image.c:1654
    #11: 0x0000000007090005 BdsDxe.dll`EfiBootManagerBoot(BootOption=0x00000000067987a0) + 1758 at /Volumes/Case/edk2-github/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c:1982
    #12: 0x0000000007088fb4 BdsDxe.dll`BdsEntry [inlined] BootBootOptions(BootOptions=0x0000000006798698, BootOptionCount=4, BootManagerMenu=0x0000000007eabc78) + 47 at /Volumes/Case/edk2-github/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:408
    #13: 0x0000000007088f85 BdsDxe.dll`BdsEntry(This=<unavailable>) + 5252 at /Volumes/Case/edk2-github/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:1062
    #14: 0x0000000007ebfa3b DxeCore.dll`DxeMain(HobStart=<unavailable>) + 7725 at /Volumes/Case/edk2-github/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:543
    #15: 0x0000000007ec146a DxeCore.dll`_ModuleEntryPoint [inlined] ProcessModuleEntryPointList(HobStart=<unavailable>) + 20 at /Volumes/Case/edk2-github/Build/OvmfX64/DEBUG_XCODE5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/AutoGen.c:462
    #16: 0x0000000007ec1465 DxeCore.dll`_ModuleEntryPoint(HobStart=<unavailable>) + 15 at /Volumes/Case/edk2-github/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:48
    #17: 0x0000000007ee3617 DxeIpl.dll`InternalSwitchStack + 15
    #18: 0x0000000007ee4970 DxeIpl.dll`DxeLoadCore [inlined] HandOffToDxeCore(HobList=EFI_PEI_HOB_POINTERS @ 0x0000000003f54900) + 4152 at /Volumes/Case/edk2-github/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c:117
    #19: 0x0000000007ee3fcd DxeIpl.dll`DxeLoadCore(This=<unavailable>, PeiServices=<unavailable>, HobList=EFI_PEI_HOB_POINTERS @ 0x0000000003f54900) + 1685 at /Volumes/Case/edk2-github/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c:449
    #20: 0x0000000007ee982a PeiCore.dll`PeiCore(SecCoreDataPtr=<unavailable>, PpiList=0x0000000000000000, Data=<unavailable>) + 732 at /Volumes/Case/edk2-github/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c:494
    #21: 0x0000000000821d3e
    #22: 0x000000000082674e
    #23: 0x0000000000827067
    #24: 0x0000000000821869
    #25: 0x0000000000828dd1
    #26: 0x00000000fffcd5b7 SecMain.dll`SecCoreStartupWithStack [inlined] SecStartupPhase2(Context=<unavailable>) + 49 at /Volumes/Case/edk2-github/OvmfPkg/Sec/SecMain.c:858
    #27: 0x00000000fffcd586 SecMain.dll`SecCoreStartupWithStack [inlined] InitializeDebugAgent(InitFlag=<unavailable>, Context=<unavailable>) at /Volumes/Case/edk2-github/MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.c:42
    #28: 0x00000000fffcd586 SecMain.dll`SecCoreStartupWithStack(BootFv=<unavailable>, TopOfCurrentStack=<unavailable>) + 421 at /Volumes/Case/edk2-github/OvmfPkg/Sec/SecMain.c:821
    #29: 0x00000000fffcc301 SecMain.dll`_ModuleEntryPoint + 45

[3] (lldb) efi_symbols -h
Usage: efi_symbols [options]

Stand alone script that can load EFI PE/COFF and TE image symbols.

Options:
  -p, --pc              Load symbols for pc
  -f, --frame           Load symbols for current stack frame
  -a ADDRESS, --address=ADDRESS
                        Load symbols for image at address
  -r RANGE, --range=RANGE
                        How far to search backward for start of PE/COFF Image
  -t, --terse           Only display filenames not paths
  -h, --help            Show help for the command

Thanks,

Andrew Fish



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

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

[Laszlo Ersek]

(+Rebecca, +Andrei)

On 05/25/20 05:30, Andrew Fish via groups.io wrote:
> The full Star Trek quote from Spock is:  " I am endeavoring, ma'am, to construct a mnemonic memory circuit using stone knives and bearskins.", but I ran across this [1], and it felt like "stone knives and bearskins." vs my experience with lldb debugging EFI. 
> 
> So a few questions:
> 1) Is this Wiki [1]  actually up to date? 
> 2) Do we have a location to add debugger scripts to the edk2? If not what location should we chose?
> 3) Is anyone interested in writing gdb scripts to do better?

Andrei used to have some utilities / scripts at
<https://github.com/andreiw/andreiw-wip/tree/master/uefi/DebugPkg>, and
Rebecca used to host an article on her website about those tools. Hm....
the URL seems to be:
<https://code.bsdio.com/w/tianocore/debugging-with-gdb/>.

I have those utilities (somewhat refreshed?) in one of my (frequently
rebased) local branches, but I've never tried to upstream them (it's not
my work, after all). But, I use gdb really rarely anyway; mostly I use
DEBUGs. :)


I think the last time we discussed this was in this thread:

https://edk2.groups.io/g/devel/message/40061

(alt link:
<http://mid.mail-archive.com/19e9d54a-575a-ee5e-8039-900f466d473d@bluestop.org>)


I don't remember ever relying on [1]
<https://github.com/tianocore/tianocore.github.io/wiki/How-to-debug-OVMF-with-QEMU-using-GDB>.

Thanks
Laszlo

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

[Andrew Fish]

> On May 25, 2020, at 12:15 PM, Laszlo Ersek <lersek@redhat.com> wrote:
> 
> (+Rebecca, +Andrei)
> 
> On 05/25/20 05:30, Andrew Fish via groups.io wrote:
>> The full Star Trek quote from Spock is:  " I am endeavoring, ma'am, to construct a mnemonic memory circuit using stone knives and bearskins.", but I ran across this [1], and it felt like "stone knives and bearskins." vs my experience with lldb debugging EFI. 
>> 
>> So a few questions:
>> 1) Is this Wiki [1]  actually up to date? 
>> 2) Do we have a location to add debugger scripts to the edk2? If not what location should we chose?
>> 3) Is anyone interested in writing gdb scripts to do better?
> 
> Andrei used to have some utilities / scripts at
> <https://github.com/andreiw/andreiw-wip/tree/master/uefi/DebugPkg>, and
> Rebecca used to host an article on her website about those tools. Hm....
> the URL seems to be:
> <https://code.bsdio.com/w/tianocore/debugging-with-gdb/>.
> 
> I have those utilities (somewhat refreshed?) in one of my (frequently
> rebased) local branches, but I've never tried to upstream them (it's not
> my work, after all). But, I use gdb really rarely anyway; mostly I use
> DEBUGs. :)
> 
> 
> I think the last time we discussed this was in this thread:
> 
> https://edk2.groups.io/g/devel/message/40061
> 
> (alt link:
> <http://mid.mail-archive.com/19e9d54a-575a-ee5e-8039-900f466d473d@bluestop.org>)
> 

Laszlo,

I was thinking more of a workflow that looks like:
$ gdb -ex " target remote localhost:1234" -ex " source efi_symbolicate.py" 

And then you are sitting at a symbolicated stack frame when gdb launches. This is what I have working with lldb and OVMF. I'll see if I can abstract out the debugger from my script and make it easy to port to gdb.

This would imply we need a location to store the debugger script, and maybe a script to launch the debugger if the command line gets long, but we could land that convenience script in OvmfPkg/. 

I see Andrei's warning about needing to load a module to get gdb to behave. We might be able to load the DXE Core or some other module at its linked address (around zero) and then unloaded when we detect its actual load address. I've got something like this working in lldb. 

Thanks,

Andrew Fish

> 
> I don't remember ever relying on [1]
> <https://github.com/tianocore/tianocore.github.io/wiki/How-to-debug-OVMF-with-QEMU-using-GDB>.
> 
> Thanks
> Laszlo
> 

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

[Rebecca Cran]

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 Cran

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

[Andrew Fish]

> 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://raw.githubusercontent.com/llvm-mirror/lldb/master/examples/python/x86_64_target_definition.py
$ 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: http://lldb.llvm.org/use/map.html

Thanks,

Andrew Fish

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

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

[Andrei Warkentin]

[-- 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 --]

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

[Laszlo Ersek]

On 05/26/20 01:14, Andrew Fish wrote:
> 
> 
>> On May 25, 2020, at 12:15 PM, Laszlo Ersek <lersek@redhat.com> wrote:
>>
>> (+Rebecca, +Andrei)
>>
>> On 05/25/20 05:30, Andrew Fish via groups.io wrote:
>>> The full Star Trek quote from Spock is:  " I am endeavoring, ma'am, to construct a mnemonic memory circuit using stone knives and bearskins.", but I ran across this [1], and it felt like "stone knives and bearskins." vs my experience with lldb debugging EFI. 
>>>
>>> So a few questions:
>>> 1) Is this Wiki [1]  actually up to date? 
>>> 2) Do we have a location to add debugger scripts to the edk2? If not what location should we chose?
>>> 3) Is anyone interested in writing gdb scripts to do better?
>>
>> Andrei used to have some utilities / scripts at
>> <https://github.com/andreiw/andreiw-wip/tree/master/uefi/DebugPkg>, and
>> Rebecca used to host an article on her website about those tools. Hm....
>> the URL seems to be:
>> <https://code.bsdio.com/w/tianocore/debugging-with-gdb/>.
>>
>> I have those utilities (somewhat refreshed?) in one of my (frequently
>> rebased) local branches, but I've never tried to upstream them (it's not
>> my work, after all). But, I use gdb really rarely anyway; mostly I use
>> DEBUGs. :)
>>
>>
>> I think the last time we discussed this was in this thread:
>>
>> https://edk2.groups.io/g/devel/message/40061
>>
>> (alt link:
>> <http://mid.mail-archive.com/19e9d54a-575a-ee5e-8039-900f466d473d@bluestop.org>)
>>
> 
> Laszlo,
> 
> I was thinking more of a workflow that looks like:
> $ gdb -ex " target remote localhost:1234" -ex " source efi_symbolicate.py" 
> 
> And then you are sitting at a symbolicated stack frame when gdb launches.

Yes, that's how I use Andrei's DebugPkg. There are 4 patches related to
that on my local branch:

(1) import Andrei's DebugPkg:

 DebugPkg/DebugPkg.dec        |  34 ++++
 DebugPkg/GdbSyms/GdbSyms.inf |  57 ++++++
 DebugPkg/GdbSyms/GdbSyms.c   |  70 +++++++
 DebugPkg/Scripts/gdb_uefi.py | 348 +++++++++++++++++++++++++++++++++++
 4 files changed, 509 insertions(+)

(2) add "DebugPkg/GdbSyms/GdbSyms.inf" (from the previous patch) to the
OvmfPkg DSC files (but not the FDF files),

(3) "DebugPkg: load unstripped image from *.debug" -- a tweak to
Andrei's DebugPkg code

(4) "DebugPkg: add localized gdb startup scripts for debugging":

 DebugPkg/Scripts/commands-32.gdb   | 7 +++++++
 DebugPkg/Scripts/commands-3264.gdb | 7 +++++++
 DebugPkg/Scripts/commands.gdb      | 7 +++++++

I do invoke these with "gdb -x". Unfortunately, they do contain absolute
pathnames that are specific to my home directory.

> This is what I have working with lldb and OVMF. I'll see if I can abstract out the debugger from my script and make it easy to port to gdb.
> 
> This would imply we need a location to store the debugger script, and maybe a script to launch the debugger if the command line gets long, but we could land that convenience script in OvmfPkg/.

Sure, I think it's OK to check those in under OvmfPkg.

> I see Andrei's warning about needing to load a module to get gdb to behave. We might be able to load the DXE Core or some other module at its linked address (around zero) and then unloaded when we detect its actual load address. I've got something like this working in lldb. 

Thanks
Laszlo