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

["Laszlo Ersek" <lersek@redhat.com>]

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