From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web10.48823.1590492187974823216 for ; Tue, 26 May 2020 04:23:08 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=I5aareoD; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590492187; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yDi5VnT0+xHL+3tT8nVcYRNJdMR1Zlql7xE7KjU7djk=; b=I5aareoD5n+IqkE6mfQir+m0lR1ufnX9riI1X5oIE63riY5CyXVobFFXMjqKJpMRYEqxq4 aRiuOn+ZgnpBTbo2ExzK/4k+H4O4+xQXQZTxutfn/E+dD3Q7krnONnU+MSWRWG8eDuIXLH EeQqMzEdGsOqG66YN6AKvzZL8eYyX4Q= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-296-r7Oek_f5OYeVaD6NpSRIvw-1; Tue, 26 May 2020 07:23:02 -0400 X-MC-Unique: r7Oek_f5OYeVaD6NpSRIvw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4108A107ACCD; Tue, 26 May 2020 11:23:01 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-136.ams2.redhat.com [10.36.114.136]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0B30E5D9E5; Tue, 26 May 2020 11:22:59 +0000 (UTC) Subject: Re: [edk2-devel] OVMF gdb seems to require "stone knives and bearskins" to debug code? To: Andrew Fish Cc: devel@edk2.groups.io, Rebecca Cran , "Andrei Warkentin (VMWare address)" References: <50EEBF6E-8BB1-461D-B252-D37D2990957D@apple.com> <01ce779e-825a-9fd3-fa7f-7db7ce589aee@redhat.com> <9734466F-4F9D-4E8B-9837-B53236051780@apple.com> From: "Laszlo Ersek" Message-ID: <6751c30e-bc35-e097-3ff0-6b37cc02c226@redhat.com> Date: Tue, 26 May 2020 13:22:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9734466F-4F9D-4E8B-9837-B53236051780@apple.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 05/26/20 01:14, Andrew Fish wrote: > > >> On May 25, 2020, at 12:15 PM, Laszlo Ersek 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 >> , and >> Rebecca used to host an article on her website about those tools. Hm.... >> the URL seems to be: >> . >> >> 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: >> ) >> > > 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