From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) by mx.groups.io with SMTP id smtpd.web11.41492.1590448516938339741 for ; Mon, 25 May 2020 16:15:17 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=szRAh+CL; spf=pass (domain: apple.com, ip: 17.171.2.72, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 04PNBLhj064690; Mon, 25 May 2020 16:14:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=HBcvTx9H+b56pFh/5oRRvTfSd0+AVHDw7OUo4HgK1EA=; b=szRAh+CLUrr2XemjSmBCM44AvqmFIMSma3j7MbnCcGHW0QAkU4jiWk54XTvj0V2z/Y5o Y230aD8AjGZWErIg2H5hsf/Bg7rvOLbBg9QOHzrtZ3+xsBAaJDBRucOPfYh5/u/soL3+ 0bSHmC1aVsUUUW//yybgj7sEdchaflOqIkwbfhWWBVm0ylC3YCLoKvUVvxZBJn5LV2MG zj0ebTwQCD/jzsiSUkwI2qOpML5X5Aq50CRbNpjieEo+6bTRktttAYY+onmTHV0jTNe/ UBBRDi3FO6t+g5seml87gdQtm52oGuEupATCYLokuMPnvp4IaT7C1JkgZimKkMJ8Y/hv JA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3172tuwd19-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 25 May 2020 16:14:58 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QAW005QDTWY8RA0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 25 May 2020 16:14:58 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QAW00D00RE62900@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 25 May 2020 16:14:58 -0700 (PDT) X-Va-A: X-Va-T-CD: a896650d2b2ee8463fb615bccff4df55 X-Va-E-CD: 1417899239537e9f91fa9996c1a966a6 X-Va-R-CD: ebc91e5e1054c40f976e0b4d4d1c6b1d X-Va-CD: 0 X-Va-ID: ea8b8c3b-1634-4411-8d5a-f026fc7bf912 X-V-A: X-V-T-CD: a896650d2b2ee8463fb615bccff4df55 X-V-E-CD: 1417899239537e9f91fa9996c1a966a6 X-V-R-CD: ebc91e5e1054c40f976e0b4d4d1c6b1d X-V-CD: 0 X-V-ID: 2edad978-9a5c-4dba-82dc-3d81d4837c3f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-05-25_10:2020-05-25,2020-05-25 signatures=0 Received: from [17.235.10.166] (unknown [17.235.10.166]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QAW0007HTWWRM00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 25 May 2020 16:14:57 -0700 (PDT) MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] OVMF gdb seems to require "stone knives and bearskins" to debug code? From: "Andrew Fish" In-reply-to: <01ce779e-825a-9fd3-fa7f-7db7ce589aee@redhat.com> Date: Mon, 25 May 2020 16:14:56 -0700 Cc: devel@edk2.groups.io, Rebecca Cran , "Andrei Warkentin (VMWare address)" Message-id: <9734466F-4F9D-4E8B-9837-B53236051780@apple.com> References: <50EEBF6E-8BB1-461D-B252-D37D2990957D@apple.com> <01ce779e-825a-9fd3-fa7f-7db7ce589aee@redhat.com> To: Laszlo Ersek X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-05-25_10:2020-05-25,2020-05-25 signatures=0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable > On May 25, 2020, at 12:15 PM, Laszlo Ersek wrote: >=20 > (+Rebecca, +Andrei) >=20 > 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.=20 >>=20 >> So a few questions: >> 1) Is this Wiki [1] actually up to date?=20 >> 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? >=20 > 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: > . >=20 > 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. :) >=20 >=20 > I think the last time we discussed this was in this thread: >=20 > https://edk2.groups.io/g/devel/message/40061 >=20 > (alt link: > = ) >=20 Laszlo, I was thinking more of a workflow that looks like: $ gdb -ex " target remote localhost:1234" -ex " source = efi_symbolicate.py"=20 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/.=20 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.=20 Thanks, Andrew Fish >=20 > I don't remember ever relying on [1] > = . >=20 > Thanks > Laszlo >=20