From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (NAM04-BN3-obe.outbound.protection.outlook.com [40.107.68.59]) by mx.groups.io with SMTP id smtpd.web12.45543.1590472666129854292 for ; Mon, 25 May 2020 22:57:46 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@vmware.com header.s=selector2 header.b=ly+nP1TV; spf=pass (domain: vmware.com, ip: 40.107.68.59, mailfrom: awarkentin@vmware.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xf1HiEV28VjSP2RbWnrgYTaS+DhMnPa96yI8lcc+MqM4tS6vVG9ktteKd4u6wRLmPayRpCzxFqu5y/7JHAqWJ4GgTczqUGb+QvJgAEMFl/YeVMtBV7+p0CWm8NVM26LDBL8p86nkl6QR/anc7ofAOYkQjGfswoEXBHKex4KSZotTTN190rqvo6YLTpnADPQeTjDHZFFW2oUJiF+NMEfP+N2ILhbHrOoODHK22poP5SCnWGgMYUez/n1K4yweI2GD2RmKSXt0ucgfjLI2w0/NRrHDKhJtOG/+P18SR/qIOY6YGbY9L8vcdMl58fWloHtJSbHE8eHbAkmrEXsI096VHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HDt101JfpJ005eZ+Isyvjgj+qw7tRXkm1PS74G39bFM=; b=X7X97lYSv/7IgT6SQzFtBTRLFHfiq2cuGpn433Xzxo5guOQllOtgKRAjdS5NvNzKPKZTQ1oJoh+2/8CxSx37B+pDJiSyo1/OWj5+eBCUyjjqc1LVhTea9fTYmE93yjzRtj4qDnjMu54gR1i103zi3aE9xQDv1EfugV7mYZ7ZlqRTZzpI/c19IJjHtNLCyc1331Rq5hz+BNV+mF/jf0zTVeT2D4e3GlAx0n9RBwlO3ECTGUr/ZmivL6B06h7bYAnLkgWAncDPpFM0HygUHJ2XazQYbm0uxQ7Oj522wrUORQVDDEuOXrDvp7zuMiO0bP+mw2X8+VKWWf6xzSWInmVbPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HDt101JfpJ005eZ+Isyvjgj+qw7tRXkm1PS74G39bFM=; b=ly+nP1TVMEszbiojnpRiQPDKGnqaMTxAceJpEFx/izwpQzxlxfi9cxryI+760xoD1RN+R0l7vRAqS86M0HN+St+Pr01lnlHO69EUDWTeDdR8/QEuo751mFqiuONinqKhwvbvFJfp+oo24VkYE+TQBMHQeySzhJL052Bs3P3u1JI= Received: from BN6PR05MB3411.namprd05.prod.outlook.com (2603:10b6:405:43::23) by BN6PR05MB2883.namprd05.prod.outlook.com (2603:10b6:404:2c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.7; Tue, 26 May 2020 05:57:43 +0000 Received: from BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::e1ef:31eb:c802:aef0]) by BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::e1ef:31eb:c802:aef0%3]) with mapi id 15.20.3045.014; Tue, 26 May 2020 05:57:43 +0000 From: "Andrei Warkentin" To: "devel@edk2.groups.io" , "rebecca@bsdio.com" , "afish@apple.com" Subject: Re: [edk2-devel] OVMF gdb seems to require "stone knives and bearskins" to debug code? Thread-Topic: [edk2-devel] OVMF gdb seems to require "stone knives and bearskins" to debug code? Thread-Index: AQHWMkTupElpQPJgkkOdQEvQIDo0p6i5o8CAgAAOhACAACqICw== Date: Tue, 26 May 2020 05:57:43 +0000 Message-ID: References: <50EEBF6E-8BB1-461D-B252-D37D2990957D@apple.com> <5ea5709b-aa92-84e5-463d-df4801635cd8@bsdio.com>,<492083F4-6955-4A32-BF56-FC5E3F04A8F0@apple.com> In-Reply-To: <492083F4-6955-4A32-BF56-FC5E3F04A8F0@apple.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: edk2.groups.io; dkim=none (message not signed) header.d=none;edk2.groups.io; dmarc=none action=none header.from=vmware.com; x-originating-ip: [98.214.99.181] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4eb58a19-0001-42f0-7e8a-08d80139b506 x-ms-traffictypediagnostic: BN6PR05MB2883: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 041517DFAB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ygx2oHvHun4poFV9yAMaBi13Ne4Qg9pFy5WiuVSw6Jhg4U4OUvZ5XyUhAr6+bvn76tJofCVbB8KsWQDblbdEMH2uhAoNYkz/TL5Pz6X2XrA5w6/6hvV2MCWUdfI6TUmoDaf/KtnVp0pbqL9Zp2XxAxvRzkc1MatVF2qPKnN1syyUdEFVJ+DCkyaqro0UmxDfN9u6PY8BBSmCE8aOwBUTis/YcEZWS2eqaV/SFZVSp0+Ydqmcm/PL/aGDkNzLjxnuBNjWTZNDLzwLN9/khjnSf0WQ6vIa5IuxQFEiSEsECFUDr2/j6seJwW7ns6/V2vYOrJPBBQpkP+aeQUMwOULDFVIqZi8A+ebL2BcSa4CCjC5b3nFL8rBK51pO6mWbS7Qr6dNCM8d9r9231dqmDiOadQ== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN6PR05MB3411.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(4636009)(366004)(346002)(376002)(396003)(136003)(39860400002)(2906002)(86362001)(71200400001)(7696005)(5660300002)(186003)(66446008)(76116006)(64756008)(6506007)(26005)(53546011)(66476007)(66556008)(66946007)(83080400001)(55016002)(9686003)(316002)(19627405001)(110136005)(966005)(8676002)(52536014)(8936002)(478600001)(33656002)(45080400002)(166002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata: aI/5SELljHu5IsJfjes6ddOAAxQePKYdx+uadTKV1MrGxuSRayr/XpYO0g/qadChQ316i8BLu94SijFaoFfL7Ur3+YmJ1v4rBSaePuVWh4ryiT3YWvhX6IiFUFJ7VkuK5dBxoxkkF7BSXSs9bwx83ThFBMx0z7QrsMDzJVuufFjsdQry09Ys1gH89ethjs9BFddERkWR19h4JvnXUqKaJO9KHzr+RCUHAaBIB6iKhxUwyUC9Wc0YbBF+q9n0KwHotleb76kQsde09enTYMeMqkcABMUnPNT202SB3An5R0PhkqwC7d914LNHCDQe97vIL6Lso3ULMtf1/x6+Ncljd1add4iXvr0U5A9y23Osi+A7kSuzY6xhgGbHR8q0uE3q0rbPeUc9zUd+GE3CMUgPnwI8nErO4nRuGZYAgf3N9iOQpO1lGWAkD8P/Ta8VkZ1fRiG01rgh2zskIlD/5UGGsgUXhToOD9+qcsS05WIsqK4= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4eb58a19-0001-42f0-7e8a-08d80139b506 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 05:57:43.3481 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4dd/dDNMg8h5ew52Q7SGkMLy81o4jASRrAwQ/uNC9yk0oin6LC6O5o4El9hxsuulyJJtcKAfsVIr8TwRMG/mog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2883 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BN6PR05MB3411784132F81B460D16FE37B9B00BN6PR05MB3411namp_" --_000_BN6PR05MB3411784132F81B460D16FE37B9B00BN6PR05MB3411namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I may not have the full context here... actually, I'm sure I don't. I am in= cidentally the original author of the DebugPkg python script[1], but if I u= nderstood correctly, it was picked up by a number of different folks over t= he years and possibly evolved separately... I certainly don't remember anyo= ne ever reaching back with improvements or anything else. Having proper deb= ug 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 alm= ost positive I tried it with AArch64 at some point, and I even tried it wit= h 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 diffe= rent arches/bitness, for example). GdbSyms does *not* need to be part of yo= ur EFI FD and is not actually executable. The script follows the UEFI spec to locate the EFI ST and the debug direct= ory 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 pai= nful - it doesn't really deal well with multiple unrelated modules occupyin= g the same address space and having same symbol names in multiple places. S= ee 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 n= eed to make UEFI debugging a reality. [ this is not upstreamed and might not even apply anymore...gdb process fo= r 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/Scrip= ts/gdb_uefi.py ________________________________ From: devel@edk2.groups.io on behalf of Andrew Fish= via groups.io Sent: Monday, May 25, 2020 10:11 PM To: devel@edk2.groups.io ; rebecca@bsdio.com Subject: Re: [edk2-devel] OVMF gdb seems to require "stone knives and bear= skins" to debug code? > On May 25, 2020, at 7:19 PM, Rebecca Cran 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 t= o 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 l= ocated 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 op= en 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 l= ldb script to use a class to abstract lldb specifics, so that should make i= t 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=3Dhttps%3A%2= F%2Fraw.githubusercontent.com%2Fllvm-mirror%2Flldb%2Fmaster%2Fexamples%2Fpy= thon%2Fx86_64_target_definition.py&data=3D02%7C01%7Cawarkentin%40vmware= .com%7C7dfa192f9f654d85b6a008d80122978c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%= 7C0%7C0%7C637260595393730625&sdata=3D82w1tZV%2Bj0J1pdnWI7WU4OTmfW%2F1BO= jm7BzvaCF8TZ4%3D&reserved=3D0 $ lldb -o "settings set plugin.process.gdb-remote.target-definition-file x= 86_64_target_definition.py" -o "gdb-remote 1234" -o "command script impor= t 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 yo= u remove importing my script that will give you assembly level debugging wi= th QEMU. But source is more interesting, unless you are really stuck. This is a good place to start to learn lldb: https://nam04.safelinks.prote= ction.outlook.com/?url=3Dhttp%3A%2F%2Flldb.llvm.org%2Fuse%2Fmap.html&da= ta=3D02%7C01%7Cawarkentin%40vmware.com%7C7dfa192f9f654d85b6a008d80122978c%7= Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637260595393730625&sdata=3D= aU3uRBIWhjealofdqjDMHKSsi0d18Z7ZNN8DlZFo5uE%3D&reserved=3D0 Thanks, Andrew Fish > > -- > Rebecca Cran > > > > > --_000_BN6PR05MB3411784132F81B460D16FE37B9B00BN6PR05MB3411namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I may not have the full context here... actually, I'm sure I don't. I am i= ncidentally 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 alm= ost positive I tried it with AArch64 at some point, and I even tried it wit= h 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 diffe= rent arches/bitness, for example). GdbSyms does *not* need to be part of yo= ur EFI FD and is not actually executable.

The script follows the UEFI spec to locate the EFI ST and the debug direct= ory 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 pai= nful - it doesn't really deal well with multiple unrelated modules occupying the same address space and havi= ng same symbol names in multiple places. See https://github.com/andre= iw/andreiw-wip/blob/master/gdb/0001-GDB-Initial-prototype-of-symbol-file-sc= ope-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 fo= r merging changes was quite bureaucratic and I never had the time to embark= on all the yak shaving activities I was asked to do ]

From: devel@edk2.groups.io= <devel@edk2.groups.io> on behalf of Andrew Fish via groups.io <af= ish=3Dapple.com@groups.io>
Sent: Monday, May 25, 2020 10:11 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; rebecca@bsdi= o.com <rebecca@bsdio.com>
Subject: Re: [edk2-devel] OVMF gdb seems to require "stone kni= ves and bearskins" to debug code?
 


> On May 25, 2020, at 7:19 PM, Rebecca Cran <rebecca@bsdio.com> w= rote:
>
> 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 h= appy 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 addres= s that is located in a loaded PE/COFF image, and when you import the command into lldb it symbolicates the current fra= me.
>
>
> As Laszlo has already explained, information about debugging with gdb= is a bit scattered. I seem to recall there were discussion about getting t= he 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 refact= ored 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=3Dhttps%3A%2F%2Fraw.gi= thubusercontent.com%2Fllvm-mirror%2Flldb%2Fmaster%2Fexamples%2Fpython%2Fx86= _64_target_definition.py&amp;data=3D02%7C01%7Cawarkentin%40vmware.com%7= C7dfa192f9f654d85b6a008d80122978c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C= 0%7C637260595393730625&amp;sdata=3D82w1tZV%2Bj0J1pdnWI7WU4OTmfW%2F1BOjm= 7BzvaCF8TZ4%3D&amp;reserved=3D0
$ lldb -o "settings set plugin.process.gdb-remote.target-definition-f= ile x86_64_target_definition.py" -o "gdb-remote 1234" &= nbsp; -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 kno= w 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 inte= resting, unless you are really stuck.

This is a good place to start to learn lldb: https://nam04.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Flldb.ll= vm.org%2Fuse%2Fmap.html&amp;data=3D02%7C01%7Cawarkentin%40vmware.com%7C= 7dfa192f9f654d85b6a008d80122978c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0= %7C637260595393730625&amp;sdata=3DaU3uRBIWhjealofdqjDMHKSsi0d18Z7ZNN8Dl= ZFo5uE%3D&amp;reserved=3D0

Thanks,

Andrew Fish

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




--_000_BN6PR05MB3411784132F81B460D16FE37B9B00BN6PR05MB3411namp_--