From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.45]) by mx.groups.io with SMTP id smtpd.web12.10957.1585142423652665305 for ; Wed, 25 Mar 2020 06:20:25 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: ispras.ru, ip: 83.149.199.45, mailfrom: cheptsov@ispras.ru) Received: from [127.0.0.1] (unknown [31.204.145.169]) by mail.ispras.ru (Postfix) with ESMTPSA id D7771725C0; Wed, 25 Mar 2020 16:20:14 +0300 (MSK) From: "Vitaly Cheptsov" Message-Id: <0D3D4386-606F-473E-9686-BC0A1C08D46E@ispras.ru> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [edk2-devel] CLANGPDB binary debugging Date: Wed, 25 Mar 2020 16:20:06 +0300 In-Reply-To: <86c6477b5a354eb98ae4e637a764dc5d@intel.com> Cc: "devel@edk2.groups.io" , Andrew Fish , =?utf-8?Q?Marvin_H=C3=A4user?= To: "Gao, Liming" References: <9804C565-0C9E-4778-92A7-06EA6AD8D694@ispras.ru> <7E18AD8F-9A44-45FE-A8C8-CE06A6328930@apple.com> <63396616-D8CF-4135-B967-772C1E6136BD@apple.com> <5C8DD065-0140-428B-A146-999A5694BC99@ispras.ru> <3D39F81F-6EBC-4079-8FC0-0112D756F0EB@ispras.ru> <86c6477b5a354eb98ae4e637a764dc5d@intel.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Groupsio-MsgNum: 56292 Content-Type: multipart/signed; boundary="Apple-Mail=_D2FB297D-3399-4E97-814F-6314E8A8B2CD"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_D2FB297D-3399-4E97-814F-6314E8A8B2CD Content-Type: multipart/alternative; boundary="Apple-Mail=_20A622B7-7708-4A3C-BA59-ACC83EE9DCEB" --Apple-Mail=_20A622B7-7708-4A3C-BA59-ACC83EE9DCEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Liming, The issue with CLANG38 is that it uses LD BFD, a GNU linker, which is not = distributed with LLVM. This makes CLANG38 to be unusable on e.g. macOS or o= ther BSD systems, where GNU linker is not used. Making CLANG38 somehow work= with LLD (e.g. by somehow providing it an environment variable to use ld.l= ld) should most likely solve the issue, but I am not positive how to addres= s it best. Best regards, Vitaly > 25 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0=B2 16:16, Gao, Limin= g =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0)= : >=20 > Vitaly: > Thanks for your further investigation with LLDB. Now, we have two CLANG= tool chain. CLANGPDB and CLANG38. CLANGPDB works with LLVM9.0 or above to = generate PE image with PDB debug symbol. CLANG38 can also be used to genera= te ELF image and convert to PE image with DWARF debug symbol on Linux host.= So, these two chains cover both usage models. We don=E2=80=99t need to int= roduce new CLANGDWARF tool chain. For LLDB issue on PDB debug symbol, I sug= gest to report them in LLVM. >=20 > Besides, LLVM10.0 is just released. >=20 > Thanks > Liming > From: devel@edk2.groups.io > On Behalf Of Vitaly Cheptsov > Sent: 2020=E5=B9=B43=E6=9C=8823=E6=97=A5 17:10 > To: Andrew Fish >; Gao, Liming = > > Cc: devel@edk2.groups.io ; Marvin H=C3=A4us= er > > Subject: Re: [edk2-devel] CLANGPDB binary debugging >=20 > Andrew, >=20 > I investigated further and was able to make some progress. I got rid of = PDB, and changed debug information generation to DWARF[1]. This resolved mo= st of LLDB crashes and made pretty-printing work just fine as type aliases = like EFI_STATUS now work correctly (I am still to commit this). Unfortunate= ly there are several downsides. Dead code stripping in LLD linker is broken= when generating PE with DWARF, so I had to patch it[2]. Debug link impleme= ntation in llvm-objcopy is also quite ugly, we do not get MTOC or anything = alike[3], just some section with a random name containing base filename. >=20 > I can submit a more proper patch to EDK II properly implementing CLANGDW= ARF toolchain instead of patching CLANGPDB like in [1], but it is questiona= ble whether it is worth it. LLVM 10 will land very soon, and the necessary = LLD patches[2] will definitely not make their way in this release. We will = have to wait for LLVM 11 at the very least, and I am not sure I am ready to= drive llvm-objcopy changes either. Liming, what do you think? >=20 > I've not used the fake image to get things done so I can't speak to that= . I have used a fake target so I could have XIP PEIM and shadowed PEIM addr= ess available at the same time. You can't have a module loaded at 2 address= es at the same time in llldb. But you might be able to use a fake target fo= r your fake stuff? >=20 > Just in case: >=20 > # create a faka target to store info about symbols > PeiXipTarget =3D target.debugger.CreateTarget (None, "i386-app= le-macosx", "remote-macosx", True, error) >=20 > # make sure the gdb-remote connection target is the active ta= rget > target.debugger.SetSelectedTarget (target) >=20 > Yes, that was actually a smart idea. I initially did it that way, as I h= ad mixing Mach-O and PE triples, but later removed, which was actually a mi= stake. Now I have a fake target for GdbSyms and a proper target for other i= mages[4]. This somewhat solves the issue with invalid addresses for gST, as= gST from DxeCore is now picked. However, I cannot access global variables = from other modules for some reason still. >=20 > If you want to inspect globals I think this logic works to get you data,= you would need to print it out etc. >=20 > SBValueList =3D lldb.target.FindGlobalVariables ("gST", 1024) > for SBValue in SBValueList: > Module =3D SBValue.GetAddress().GetModule() > ModuleStr =3D SBValue.GetAddress().GetModule().GetFileSpec().Get= Filename() > Start =3D int (SBValue.GetLocation(), 0) > End =3D Start + SBValue.GetByteSize() - 1 > SBDeclaration =3D SBValue.GetDeclaration() > Column =3D SBDeclaration.GetColumn() >=20 > I wrote a command in the early days to dump out all the instances of a g= lobal. >=20 > You can also try (lldb) image lookup -Av --name gST >=20 > Something is really weird, gST from the first image shows, but lldb beli= eves that it does not exist. lldb.target.FindGlobalVariables ("gST", 1024) = also returns an empty list. >=20 > I noticed that LLDB shows invalid type for gST in the symtab, there also= is no address. I started to wonder whether this is the cause and decided t= o check XCODE5, as the the issue could have been with PE format. Unfortunat= ely even after I tried XCODE5 support with LLDB, I got exactly the same pro= blem. I am quite clueless what is going on. Below I included two transcript= s: for CLANGDWARF and XCODE5. >=20 > (lldb) p gST > (EFI_SYSTEM_TABLE *) $0 =3D 0x000000007f9ee018 > (lldb) p *gST > (EFI_SYSTEM_TABLE) $1 =3D { > Hdr =3D (Signature =3D 0x5453595320494249, Revision =3D 0x00020046, He= aderSize =3D 0x00000078, CRC32 =3D 0x3d5e9b5d, Reserved =3D 0x00000000) > FirmwareVendor =3D 0x000000007f9e9c98 > FirmwareRevision =3D 0x00010000 > ConsoleInHandle =3D 0x000000007ed58f18 > ConIn =3D 0x000000007e6edcb8 > ConsoleOutHandle =3D 0x000000007ed57018 > ConOut =3D 0x000000007e6ede40 > StandardErrorHandle =3D 0x000000007ed57a98 > StdErr =3D 0x000000007e6ee030 > RuntimeServices =3D 0x000000007f9eeb98 > BootServices =3D 0x000000007fe689e8 > NumberOfTableEntries =3D 0x000000000000000a > ConfigurationTable =3D 0x000000007f9eec98 > } > (lldb) image lookup -Av --name gST > (lldb) image dump sections > Dumping sections for 90 modules. > Sections for '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_CL= ANGPDB/X64/DxeCore.debug' (x86_64): > SectID Type Load Address P= erm File Off. File Size Flags Section Name > ---------- ---------------- --------------------------------------- -= --- ---------- ---------- ---------- ---------------------------- > 0xffffffffffffffff container [0x000000007fe1b000-0x000000007ff3= 8ac0) --- 0x00000000 0x00000000 0x00000000 DxeCore.debug. > 0x00000001 code [0x000000007fe1b320-0x000000007fe61f34) -= -- 0x00000320 0x00046c20 0x60000020 DxeCore.debug...text > 0x00000002 data [0x000000007fe61f40-0x000000007fe680f1) -= -- 0x00046f40 0x000061c0 0x40000040 DxeCore.debug...rdata > 0x00000003 data [0x000000007fe68100-0x000000007fe6d1e0) -= -- 0x0004d100 0x000018a0 0xc0000040 DxeCore.debug...data > 0x00000004 regular [0x000000007fe6d1e0-0x000000007fe6d424) -= -- 0x0004e9a0 0x00000260 0x42000040 DxeCore.debug...reloc > 0x00000005 dwarf-abbrev [0x000000007fe6d440-0x000000007fe74059) -= -- 0x0004ec00 0x00006c20 0x42000040 DxeCore.debug...debug_abbrev > 0x00000006 dwarf-info [0x000000007fe74060-0x000000007fec1355) -= -- 0x00055820 0x0004d300 0x42000040 DxeCore.debug...debug_info > 0x00000007 dwarf-line [0x000000007fec1360-0x000000007fef9fd4) -= -- 0x000a2b20 0x00038c80 0x42000040 DxeCore.debug...debug_line > 0x00000008 dwarf-macinfo [0x000000007fef9fe0-0x000000007fefa056) -= -- 0x000db7a0 0x00000080 0x42000040 DxeCore.debug...debug_macinfo > 0x00000009 dwarf-ranges [0x000000007fefa060-0x000000007feff610) -= -- 0x000db820 0x000055c0 0x42000040 DxeCore.debug...debug_ranges > 0x0000000a dwarf-str [0x000000007feff620-0x000000007ff38abd) -= -- 0x000e0de0 0x000394a0 0x42000040 DxeCore.debug...debug_str > Sections for '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_CL= ANGPDB/X64/DevicePathDxe.debug' (x86_64): > SectID Type Load Address P= erm File Off. File Size Flags Section Name > ---------- ---------------- --------------------------------------- -= --- ---------- ---------- ---------- ---------------------------- > 0xffffffffffffffff container [0x000000007f986000-0x000000007f9c= b0a0) --- 0x00000000 0x00000000 0x00000000 DevicePathDxe.debug. > 0x00000001 code [0x000000007f986320-0x000000007f996dc6) -= -- 0x00000320 0x00010ac0 0x60000020 DevicePathDxe.debug...text > 0x00000002 data [0x000000007f996de0-0x000000007f999b75) -= -- 0x00010de0 0x00002da0 0x40000040 DevicePathDxe.debug...rdata > 0x00000003 data [0x000000007f999b80-0x000000007f99a202) -= -- 0x00013b80 0x00000660 0xc0000040 DevicePathDxe.debug...data > 0x00000004 regular [0x000000007f99a220-0x000000007f99a464) -= -- 0x000141e0 0x00000260 0x42000040 DevicePathDxe.debug...reloc > 0x00000005 dwarf-abbrev [0x000000007f99a480-0x000000007f99bd09) -= -- 0x00014440 0x000018a0 0x42000040 DevicePathDxe.debug...debug_abbrev > 0x00000006 dwarf-info [0x000000007f99bd20-0x000000007f9ad8b7) -= -- 0x00015ce0 0x00011ba0 0x42000040 DevicePathDxe.debug...debug_info > 0x00000007 dwarf-line [0x000000007f9ad8c0-0x000000007f9bc1f7) -= -- 0x00027880 0x0000e940 0x42000040 DevicePathDxe.debug...debug_line > 0x00000008 dwarf-macinfo [0x000000007f9bc200-0x000000007f9bc223) -= -- 0x000361c0 0x00000040 0x42000040 DevicePathDxe.debug...debug_macinfo > 0x00000009 dwarf-ranges [0x000000007f9bc240-0x000000007f9be020) -= -- 0x00036200 0x00001de0 0x42000040 DevicePathDxe.debug...debug_ranges > 0x0000000a dwarf-str [0x000000007f9be020-0x000000007f9cb099) -= -- 0x00037fe0 0x0000d080 0x42000040 DevicePathDxe.debug...debug_str > =E2=80=A6 > (lldb) image dump symtab > Dumping symbol table for 90 modules. > Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT= _CLANGPDB/X64/DxeCore.debug, num_symbols =3D 4343: > Debug symbol > |Synthetic symbol > ||Externally Visible > ||| > Index UserID DSX Type File Address/Value Load Address = Size Flags Name > ------- ------ --- --------------- ------------------ ------------------= ------------------ ---------- ---------------------------------- > [ 0] 4294967295 Invalid 0x0000000000000000 0x000000007fe1= b000 0x000000000000003a 0x00000000 .text > [ 1] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .data > [ 2] 4294967295 Invalid 0x0000000000001898 = 0x0000000000000000 0x00000000 .bss > [ 3] 4294967295 Invalid 0x0000000000046bc0 0x000000007fe6= 1bc0 0x0000000000000374 0x00000000 .text$_ModuleEntryPoint > [ 4] 4294967295 Code 0x0000000000046bc0 0x000000007fe6= 1bc0 0x0000000000000374 0x00000000 _ModuleEntryPoint > [ 5] 4294967295 Invalid 0x0000000000001b08 = 0x0000000000000000 0x00000000 .bss$gHobList > [ 6] 4294967295 Invalid 0x0000000000001b08 = 0x0000000000000000 0x00000000 gHobList > [ 7] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .rdata > [ 8] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .str > [ 9] 4294967295 Invalid 0x0000000000000058 = 0x0000000000000000 0x00000000 .rdata > [ 10] 4294967295 Invalid 0x0000000000000058 = 0x0000000000000000 0x00000000 .str.1 > [ 11] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .debug_str > [ 12] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .debug_abbrev > [ 13] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .debug_info > [ 14] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .debug_ranges > [ 15] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .debug_macinfo > [ 16] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .debug_line > [ 17] 4294967295 Code 0x000000000003f680 0x000000007fe5= a680 0x0000000000000020 0x00000000 ProcessModuleEntryPointList > [ 18] 4294967295 Code 0x0000000000023130 0x000000007fe3= e130 0x0000000000000020 0x00000000 DebugAssertEnabled > [ 19] 4294967295 Code 0x0000000000023060 0x000000007fe3= e060 0x00000000000000d0 0x00000000 DebugAssert > [ 20] 4294967295 Code 0x0000000000022150 0x000000007fe3= d150 0x0000000000000020 0x00000000 CpuDeadLoop > [ 21] 4294967295 Invalid 0x0000000000000000 0x000000007fe1= b000 0x000000000000003a 0x00000000 .text > [ 22] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .data > [ 23] 4294967295 Invalid 0x0000000000001898 = 0x0000000000000000 0x00000000 .bss > [ 24] 4294967295 Invalid 0x000000000003f240 0x000000007fe5= a240 0x0000000000000440 0x00000000 .text$ProcessLibraryConstructorList > [ 25] 4294967295 Code 0x000000000003f240 0x000000007fe5= a240 0x0000000000000440 0x00000000 ProcessLibraryConstructorList > [ 26] 4294967295 Invalid 0x000000000003f680 0x000000007fe5= a680 0x0000000000000020 0x00000000 .text$ProcessModuleEntryPointList > [ 27] 4294967295 Invalid 0x0000000000000070 = 0x0000000000000000 0x00000000 .data$gEfiCallerIdGuid > [ 28] 4294967295 Invalid 0x0000000000000070 = 0x0000000000000000 0x00000000 gEfiCallerIdGuid > [ 29] 4294967295 Invalid 0x0000000000000148 = 0x0000000000000000 0x00000000 .data$gEfiEventMemoryMapChangeGuid > [ 30] 4294967295 Invalid 0x0000000000000148 = 0x0000000000000000 0x00000000 gEfiEventMemoryMapChangeGuid > [ 31] 4294967295 Invalid 0x0000000000000168 = 0x0000000000000000 0x00000000 .data$gEfiEventVirtualAddressChangeGuid > [ 32] 4294967295 Invalid 0x0000000000000168 = 0x0000000000000000 0x00000000 gEfiEventVirtualAddressChangeGuid > [ 33] 4294967295 Invalid 0x0000000000000138 = 0x0000000000000000 0x00000000 .data$gEfiEventExitBootServicesGuid > [ 34] 4294967295 Invalid 0x0000000000000138 = 0x0000000000000000 0x00000000 gEfiEventExitBootServicesGuid > =E2=80=A6. > [ 303] 4294967295 Invalid 0x0000000000001b60 = 0x0000000000000000 0x00000000 .bss$gST > [ 304] 4294967295 Invalid 0x0000000000001b60 = 0x0000000000000000 0x00000000 gST > [ 305] 4294967295 Invalid 0x00000000000018a0 = 0x0000000000000000 0x00000000 .bss$gBS > [ 306] 4294967295 Invalid 0x00000000000018a0 = 0x0000000000000000 0x00000000 gBS > =E2=80=A6 >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >=20 > (lldb) p gST > (EFI_SYSTEM_TABLE *) $2 =3D 0x000000007fbee018 > (lldb) p &gST > (EFI_SYSTEM_TABLE **) $4 =3D 0x000000007fe6d788 > (lldb) p *gST > (EFI_SYSTEM_TABLE) $3 =3D { > Hdr =3D (Signature =3D 0x5453595320494249, Revision =3D 0x00020046, He= aderSize =3D 0x00000078, CRC32 =3D 0x5355dbe2, Reserved =3D 0x00000000) > FirmwareVendor =3D 0x000000007fbe9c98 > FirmwareRevision =3D 0x00010000 > ConsoleInHandle =3D 0x000000007ede5a98 > ConIn =3D 0x000000007e95f640 > ConsoleOutHandle =3D 0x000000007ede4e98 > ConOut =3D 0x000000007e95f800 > StandardErrorHandle =3D 0x000000007ede4b98 > StdErr =3D 0x000000007e95f910 > RuntimeServices =3D 0x000000007fbeeb98 > BootServices =3D 0x000000007fe6cde8 > NumberOfTableEntries =3D 0x0000000000000009 > ConfigurationTable =3D 0x000000007fbeec98 > } > (lldb) image lookup -Av --name gST > (lldb) image dump sections > Dumping sections for 88 modules. > Sections for '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_XC= ODE5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll' (x86_64): > SectID Type Load Address P= erm File Off. File Size Flags Section Name > ---------- ---------------- --------------------------------------- -= --- ---------- ---------- ---------- ---------------------------- > 0x00000100 container [0x000000007fe26240-0x000000007fe6bb40) r= -x 0x000004a0 0x00045900 0x00000000 DxeCore.dll.__TEXT > 0x00000001 code [0x000000007fe26240-0x000000007fe65bd8) r= -x 0x000004a0 0x0003f998 0x80000400 DxeCore.dll.__TEXT.__text > 0x00000002 data-cstr [0x000000007fe65bd8-0x000000007fe6ba23) r= -x 0x0003fe38 0x00005e4b 0x00000002 DxeCore.dll.__TEXT.__cstring > 0x00000003 regular [0x000000007fe6ba24-0x000000007fe6ba6c) r= -x 0x00045c84 0x00000048 0x00000000 DxeCore.dll.__TEXT.__ustring > 0x00000004 regular [0x000000007fe6ba70-0x000000007fe6bb40) r= -x 0x00045cd0 0x000000d0 0x00000000 DxeCore.dll.__TEXT.__const > 0x00000200 container [0x000000007fe6bb40-0x000000007fe70e60) r= w- 0x00045da0 0x00001ae0 0x00000000 DxeCore.dll.__DATA > 0x00000005 regular [0x000000007fe6bb40-0x000000007fe6bd58) r= w- 0x00045da0 0x00000218 0x00000000 DxeCore.dll.__DATA.__const > 0x00000006 data [0x000000007fe6bd60-0x000000007fe6d610) r= w- 0x00045fc0 0x000018b0 0x00000000 DxeCore.dll.__DATA.__data > 0x00000007 zero-fill [0x000000007fe6d610-0x000000007fe70e20) r= w- 0x00000000 0x00000000 0x00000001 DxeCore.dll.__DATA.__common > 0x00000008 zero-fill [0x000000007fe70e20-0x000000007fe70e58) r= w- 0x00000000 0x00000000 0x00000001 DxeCore.dll.__DATA.__bss > 0x00000100 container [0x000000000004b000-0x00000000000ef000)* r= w- 0x00001000 0x000a3a74 0x00000000 DxeCore.dll.__DWARF > 0x00000001 dwarf-line [0x000000000004b000-0x00000000000723fb)* r= w- 0x00001000 0x000273fb 0x00000000 DxeCore.dll.__DWARF.__debug_line > 0x00000002 dwarf-pubnames [0x00000000000723fb-0x0000000000078429)* r= w- 0x000283fb 0x0000602e 0x00000000 DxeCore.dll.__DWARF.__debug_pubnames > 0x00000003 dwarf-pubtypes [0x0000000000078429-0x000000000008b915)* r= w- 0x0002e429 0x000134ec 0x00000000 DxeCore.dll.__DWARF.__debug_pubtypes > 0x00000004 dwarf-aranges [0x000000000008b915-0x000000000008ea65)* r= w- 0x00041915 0x00003150 0x00000000 DxeCore.dll.__DWARF.__debug_aranges > 0x00000005 dwarf-info [0x000000000008ea65-0x00000000000c78bf)* r= w- 0x00044a65 0x00038e5a 0x00000000 DxeCore.dll.__DWARF.__debug_info > 0x00000006 dwarf-frame [0x00000000000c78bf-0x00000000000cc697)* r= w- 0x0007d8bf 0x00004dd8 0x00000000 DxeCore.dll.__DWARF.__debug_frame > 0x00000007 dwarf-ranges [0x00000000000cc697-0x00000000000cc757)* r= w- 0x00082697 0x000000c0 0x00000000 DxeCore.dll.__DWARF.__debug_ranges > 0x00000008 dwarf-abbrev [0x00000000000cc757-0x00000000000cca9b)* r= w- 0x00082757 0x00000344 0x00000000 DxeCore.dll.__DWARF.__debug_abbrev > 0x00000009 dwarf-str [0x00000000000cca9b-0x00000000000dcc05)* r= w- 0x00082a9b 0x0001016a 0x00000000 DxeCore.dll.__DWARF.__debug_str > 0x0000000a apple-names [0x00000000000dcc05-0x00000000000e2439)* r= w- 0x00092c05 0x00005834 0x00000000 DxeCore.dll.__DWARF.__apple_names > 0x0000000b apple-namespaces [0x00000000000e2439-0x00000000000e245d)* r= w- 0x00098439 0x00000024 0x00000000 DxeCore.dll.__DWARF.__apple_namespac > 0x0000000c apple-types [0x00000000000e245d-0x00000000000eea50)* r= w- 0x0009845d 0x0000c5f3 0x00000000 DxeCore.dll.__DWARF.__apple_types > 0x0000000d apple-objc [0x00000000000eea50-0x00000000000eea74)* r= w- 0x000a4a50 0x00000024 0x00000000 DxeCore.dll.__DWARF.__apple_objc > Sections for '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_XC= ODE5/X64/MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe/DEBUG/DevicePat= hDxe.dll' (x86_64): > =E2=80=A6 > (lldb) image dump symtab > Dumping symbol table for 88 modules. > Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT= _XCODE5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll, num_symbols = =3D 1203: > Debug symbol > |Synthetic symbol > ||Externally Visible > ||| > Index UserID DSX Type File Address/Value Load Address = Size Flags Name > ------- ------ --- --------------- ------------------ ------------------= ------------------ ---------- ---------------------------------- > [ 0] 118 D SourceFile 0x0000000000000000 = Sibling -> [ 20] 0x00640000 /Users/user/Documents/UefiPackages/MdeModule= Pkg/Core/Dxe/SectionExtraction/CoreSectionExtraction.c > [ 1] 120 D ObjectFile 0x000000005e78588d = 0x0000000000000000 0x00660001 /Users/user/Documents/UefiWorkspace/Build/Ov= mfX64/NOOPT_XCODE5/X64/MdeModulePkg/Core/Dxe/DxeMain/OUTPUT/DxeCore.lib(Cor= eSectionExtraction.obj) > [ 2] 122 D X Code 0x0000000000000240 0x000000007fe26240= 0x0000000000000260 0x000f0000 CustomGuidedSectionExtract > [ 3] 126 D X Code 0x00000000000004a0 0x000000007fe264a0= 0x0000000000000110 0x000f0000 InitializeSectionExtraction > [ 4] 130 D X Code 0x00000000000005b0 0x000000007fe265b0= 0x0000000000000140 0x000f0000 IsValidSectionStream > [ 5] 134 D X Code 0x00000000000006f0 0x000000007fe266f0= 0x0000000000000180 0x000f0000 OpenSectionStreamEx > [ 6] 138 D X Code 0x0000000000000870 0x000000007fe26870= 0x0000000000000070 0x000f0000 OpenSectionStream > [ 7] 142 D X Code 0x00000000000008e0 0x000000007fe268e0= 0x0000000000000100 0x000f0000 ChildIsType > =E2=80=A6 > [ 831] 2470 D X Code 0x00000000000306b0 0x000000007fe566b0= 0x00000000000000f4 0x000f0000 UefiBootServicesTableLibConstructor > [ 832] 2473 D X Data 0x0000000000047780 0x000000007fe6d780= 0x0000000000000008 0x000f0000 gImageHandle > [ 833] 2474 D X Data 0x0000000000047788 0x000000007fe6d788= 0x0000000000000008 0x000f0000 gST > [ 834] 2475 D X Data 0x0000000000047790 0x000000007fe6d790= 0x0000000000000008 0x000f0000 gBS > =E2=80=A6 >=20 > This is easy enough to check as %rpb is the frame pointer so it will get= saved/restored on function entry/exit. >=20 > Actually it is fine. I happened to break in the interrupt routine, which= was not mapped for a particular image. After I stepped a little, it soon r= eached the debug symbols: >=20 > (lldb) bt all > * thread #1, stop reason =3D instruction step over > * frame #0: 0x000000007fe49f3c DxeCore.dll`CoreRestoreTpl(NewTpl=3D0x0= 000000000000008) at Tpl.c:102:12 > frame #1: 0x000000007e518c95 > thread #2 > frame #0: 0x000000007fb3ff88 CpuDxe.dll`CpuSleep + 1 > frame #1: 0x000000007fb4d719 CpuDxe.dll`ApWakeupFunction(ExchangeInf= o=3D0x0000000000087198, ApIndex=3D0x0000000000000001) at MpLib.c:768:9 > frame #2: 0x000000007fb2d151 > thread #3 > frame #0: 0x000000007fb3ff88 CpuDxe.dll`CpuSleep + 1 > frame #1: 0x000000007fb4d719 CpuDxe.dll`ApWakeupFunction(ExchangeInf= o=3D0x0000000000087198, ApIndex=3D0x0000000000000002) at MpLib.c:768:9 > frame #2: 0x000000007fb2d151 > thread #4 > frame #0: 0x000000007fb3ff88 CpuDxe.dll`CpuSleep + 1 > frame #1: 0x000000007fb4d719 CpuDxe.dll`ApWakeupFunction(ExchangeInf= o=3D0x0000000000087198, ApIndex=3D0x0000000000000003) at MpLib.c:768:9 > frame #2: 0x000000007fb2d151 >=20 > Best wishes, > Vitaly >=20 > [1] https://github.com/acidanthera/OpenCorePkg/blob/7684a9f/Debug/ClangD= warf.patch > [2] https://bugs.llvm.org/show_bug.cgi?id=3D45273 > [3] https://bugs.llvm.org/show_bug.cgi?id=3D45277 > [4] https://github.com/acidanthera/OpenCorePkg/commit/3e5f3f3f9a8d3f1978= 34bbfcf5029f771df89754 >=20 >=20 > 22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0=B2 00:06, Andrew Fis= h > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= = =D0=B0=D0=BB(=D0=B0): >=20 >=20 >=20 >=20 > On Mar 21, 2020, at 11:36 AM, Vitaly Cheptsov > wrote: >=20 > Andrew, >=20 > Thanks once again, but unfortunately it is not that simple. Below I answ= ered inline explaining the particular issues, which mostly seem to be speci= fic to CLANGPDB. LLVM stack emits PDB debug files, and even though LLDB doe= s support them to some level, it is unlikely that this will be working well= enough soon. We should really stick to more or less native debug formats, = ideally those that have proper open specifications, on all platforms, and f= or Unix that=E2=80=99s DWARF. >=20 >=20 > Vitaly, >=20 > I understand and I use the Xcode clang and not the CLANGPDB, but I use l= ldb a lot I was just trying to point out what works with Xcode. >=20 >=20 >=20 > I am pretty sure LLVM can be taught to emit DWARF debug information even= for PE files. Perhaps we can either make some option or provide a separate= toolchain for this? Another way would be recovering CLANGELF as originally= suggested. >=20 >=20 > There was a bug recently in the x86_64-pc-win32-macho triple and we had= to add -gdwarf to force it emit dwarf. Not sure what that compiler flag wo= uld do to CLANGPDB but it is worth a try? Last flag wins for the compiler. >=20 >=20 >=20 > You can teach lldb about types. There is some example code here: https:/= /github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py >=20 > This code works just fine with LLDB and DWARF (e.g. XCODE5), though I ha= ve not yet completed these changes for my scripts for LLDB, only for GDB. H= owever, with CLANGPDB generated files it is not functional. The reason for = this is because LLDB is unaware of the underlying type, i.e. it does not kn= ow what is EFI_STATUS or UINT32. I can implement pretty-printing when LLDB = knows about a typedef, but it is not possible to do this when the debug inf= ormation is already gone or not parsed: >=20 > (lldb) p Status > (unsigned long long) $1 =3D 0 > (lldb) p &Status > (unsigned long long *) $2 =3D 0x000000007fe19ad8 > (lldb) p (EFI_STATUS)Status > error: use of undeclared identifier 'EFI_STATUS' >=20 > Just in case I tried using exactly your code, and other stuff like sourc= e level debugging works just fine and symbolication works fine, so it shoul= d be some bug with PDB in particular. >=20 >=20 > That is strange as globals usually work best? The common issue I've seen= is getting the slide wrong. The EFI modules are linked at a value near zer= o and relocated into memory, so the slide represents that adjustment. >=20 > You can use `image dump sections` and ` image dump symtab` to see lldb's= view of symbols. More info here [1]. >=20 > Yes, this one is a bit complicated, once again due to PDB most likely. I= t knows about global symbols, but does not list them in symtab: >=20 > (lldb) image dump symtab > Dumping symbol table for 91 modules. > Symtab, file =3D GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll, num_symbols =3D 0 > Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT= _CLANGPDB/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll, num_symbols = = =3D 0 > Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT= _CLANGPDB/X64/MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe/DEBUG/Devi= cePathDxe.dll, num_symbols =3D 0 > =E2=80=A6 >=20 > The slides are correct, but there are two nuances that collide with it. >=20 > 1. There are multiple instances of the globals with the same name (e.g. = gBS), but for some reason LLDB always tries to print the globals from the f= irst module. This happens even when I am source-level debugging, and I see = a gBS symbol from another module (e.g. DxeCore) used right at the same line= . With GDB the closest symbol is used, but with LLDB it is always coming fr= om the first module. I tried checking expr help to find whether I can pass = it a module explicitly, but also failed. >=20 >=20 > Usually what happens with lldb is you get the global that is in scope fo= r the current frame. >=20 >=20 > 2. To be able to get EFI types to locate the EFI_SYSTEM_TABLE_POINTER I= add a dummy GdbSyms image, which is not loaded to the firmware. So basical= ly I cannot slide what is not in the memory, and this is also my first imag= e. I tried deleting it anyhow, but it failed for me. >=20 >=20 > I've not used the fake image to get things done so I can't speak to that= . I have used a fake target so I could have XIP PEIM and shadowed PEIM addr= ess available at the same time. You can't have a module loaded at 2 address= es at the same time in llldb. But you might be able to use a fake target fo= r your fake stuff? >=20 > Just in case: >=20 > # create a faka target to store info about symbols > PeiXipTarget =3D target.debugger.CreateTarget (None, "i386-app= le-macosx", "remote-macosx", True, error) >=20 > # make sure the gdb-remote connection target is the active ta= rget > target.debugger.SetSelectedTarget (target) >=20 >=20 >=20 > (lldb) image dump sections > Dumping sections for 91 modules. > Sections for 'GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll' (x86_64): > SectID Type Load Address P= erm File Off. File Size Flags Section Name > ---------- ---------------- --------------------------------------- -= --- ---------- ---------- ---------- ---------------------------- > 0xffffffffffffffff container [0x0000000000000000-0x000000000000= 6ec0)* --- 0x00000000 0x00000000 0x00000000 GdbSyms.dll. > 0x00000001 code [0x0000000000000220-0x0000000000005bd6)* -= -- 0x00000220 0x000059c0 0x60000020 GdbSyms.dll...text > 0x00000002 data [0x0000000000005be0-0x0000000000006d79)* -= -- 0x00005be0 0x000011a0 0x40000040 GdbSyms.dll...rdata > 0x00000003 data [0x0000000000006d80-0x0000000000006e30)* -= -- 0x00006d80 0x00000060 0xc0000040 GdbSyms.dll...data > 0x00000004 regular [0x0000000000006e40-0x0000000000006ea4)* -= -- 0x00006de0 0x00000080 0x42000040 GdbSyms.dll...reloc > Sections for '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_CL= ANGPDB/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll' (x86_64): > SectID Type Load Address P= erm File Off. File Size Flags Section Name > ---------- ---------------- --------------------------------------- -= --- ---------- ---------- ---------- ---------------------------- > 0xffffffffffffffff container [0x0000000000000000-0x000000000005= 23a0)* --- 0x00000000 0x00000000 0x00000000 DxeCore.dll. > 0x00000001 code [0x000000007fe1b220-0x000000007fe61e34) -= -- 0x00000220 0x00046c20 0x60000020 DxeCore.dll...text > 0x00000002 data [0x000000007fe61e40-0x000000007fe68065) -= -- 0x00046e40 0x00006240 0x40000040 DxeCore.dll...rdata > 0x00000003 data [0x000000007fe68080-0x000000007fe6d160) -= -- 0x0004d080 0x000018a0 0xc0000040 DxeCore.dll...data > 0x00000004 regular [0x000000007fe6d160-0x000000007fe6d398) -= -- 0x0004e920 0x00000240 0x42000040 DxeCore.dll...reloc > Sections for '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_CL= ANGPDB/X64/MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe/DEBUG/DeviceP= athDxe.dll' (x86_64): > SectID Type Load Address P= erm File Off. File Size Flags Section Name > ---------- ---------------- --------------------------------------- -= --- ---------- ---------- ---------- ---------------------------- > 0xffffffffffffffff container [0x0000000000000000-0x000000000001= 4420)* --- 0x00000000 0x00000000 0x00000000 DevicePathDxe.dll. > 0x00000001 code [0x000000007f986220-0x000000007f996cc6) -= -- 0x00000220 0x00010ac0 0x60000020 DevicePathDxe.dll...text > 0x00000002 data [0x000000007f996ce0-0x000000007f999b04) -= -- 0x00010ce0 0x00002e40 0x40000040 DevicePathDxe.dll...rdata > 0x00000003 data [0x000000007f999b20-0x000000007f99a1a2) -= -- 0x00013b20 0x00000660 0xc0000040 DevicePathDxe.dll...data > 0x00000004 regular [0x000000007f99a1c0-0x000000007f99a404) -= -- 0x00014180 0x00000260 0x42000040 DevicePathDxe.dll=E2=80=A6reloc > =E2=80=A6 >=20 > So, all in all, unique global variables work, but there is no way to acc= ess duplicating variables. They either resolve to GdbSyms or just cause a c= rash: >=20 > (lldb) p mDebugInfoTableHeader > (EFI_DEBUG_IMAGE_INFO_TABLE_HEADER) $0 =3D { > UpdateStatus =3D 2 > TableSize =3D 92 > EfiDebugImageInfoTable =3D 0x000000007f814018 > } > (lldb) p gBS > error: Couldn't materialize: couldn't get the value of variable ::gBS: r= ead memory from 0x6df8 failed > error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression > (lldb) p gEfiGlobalVariableGuid > 0 libLLVM.dylib 0x000000010e52ee68 llvm::sys::PrintStackTrac= e(llvm::raw_ostream&) + 40 > 1 libLLVM.dylib 0x000000010e52f262 SignalHandler(int) + 188 > 2 libsystem_platform.dylib 0x00007fff6ca5642d _sigtramp + 29 > ... >=20 >=20 > If you want to inspect globals I think this logic works to get you data,= you would need to print it out etc. >=20 > SBValueList =3D lldb.target.FindGlobalVariables ("gST", 1024) > for SBValue in SBValueList: > Module =3D SBValue.GetAddress().GetModule() > ModuleStr =3D SBValue.GetAddress().GetModule().GetFileSpec().Get= Filename() > Start =3D int (SBValue.GetLocation(), 0) > End =3D Start + SBValue.GetByteSize() - 1 > SBDeclaration =3D SBValue.GetDeclaration() > Column =3D SBDeclaration.GetColumn() >=20 > I wrote a command in the early days to dump out all the instances of a g= lobal. >=20 > You can also try (lldb) image lookup -Av --name gST >=20 >=20 > You can tell lldb to use the older Python like this (from the Terminal.a= pp): > $ defaults write com.apple.dt.lldb DefaultPythonVersion 2 >=20 > Thanks, that helped quite a bit, but for some reason Xcode version still= crashes more for me. I attached a couple of stack traces if you feel like = having a look, but once again it seems that it is all about the PDB plugin. >=20 > For the macOS API clang emits frame pointers, so you can walk the stack = without symbols. You could try adding the compiler flag to emit the frame p= ointers. >=20 >=20 > This is easy enough to check as %rpb is the frame pointer so it will get= saved/restored on function entry/exit. >=20 >=20 > I am pretty sure stack frames are not disabled with UEFI, as sometimes b= acktracing works just fine. To me it looks like debug information parsing r= andomly breaks in LLDB, and once it happens it forgets about other images: >=20 > (lldb) b CoreLocateHandleBuffer > Breakpoint 2: where =3D DxeCore.dll`CoreLocateHandleBuffer + 31 at Locat= e.c:649, address =3D 0x000000007fe36e4f > (lldb) c > Process 1 resuming > Process 1 stopped > * thread #1, stop reason =3D breakpoint 2.1 > frame #0: 0x000000007fe36e4f DxeCore.dll`CoreLocateHandleBuffer(Sear= chType=3DByProtocol, Protocol=3D0x000000007f978160, SearchKey=3D0x000000000= 0000000, NumberHandles=3D0x000000007fe19fd8, Buffer=3D0x000000007fe19fc0) a= t Locate.c:649 > 646 EFI_STATUS Status; > 647 UINTN BufferSize; > 648 > -> 649 if (NumberHandles =3D=3D NULL) { > 650 return EFI_INVALID_PARAMETER; > 651 } > 652 > (lldb) bt > * thread #1, stop reason =3D breakpoint 2.1 > * frame #0: 0x000000007fe36e4f DxeCore.dll`CoreLocateHandleBuffer(Sear= chType=3DByProtocol, Protocol=3D0x000000007f978160, SearchKey=3D0x000000000= 0000000, NumberHandles=3D0x000000007fe19fd8, Buffer=3D0x000000007fe19fc0) a= t Locate.c:649 > frame #1: 0x000000007fe36816 DxeCore.dll`CoreLocateDevicePath(Protoc= ol=3D0x000000007f978160, DevicePath=3D0x000000007fe1a060, Device=3D0x000000= 007fe1a068) at Locate.c:466 > frame #2: 0x000000007f97479a SecurityStubDxe.dll >=20 > =E2=80=94=E2=80=94=E2=80=94 >=20 > (lldb) b CopyMem > Breakpoint 3: 70 locations. > (lldb) c > Process 1 resuming > Process 1 stopped > * thread #1, stop reason =3D breakpoint 2.53 3.53 > frame #0: 0x000000007e5c13b3 MnpDxe.dll`CopyMem(DestinationBuffer=3D= 0x000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at Cop= yMemWrapper.c:47 > 44 IN UINTN Length > 45 ) > 46 { > -> 47 if (Length =3D=3D 0) { > 48 return DestinationBuffer; > 49 } > 50 ASSERT ((Length - 1) <=3D (MAX_ADDRESS - (UINTN)Destination= Buffer)); > (lldb) bt > * thread #1, stop reason =3D breakpoint 2.53 3.53 > * frame #0: 0x000000007e5c13b3 MnpDxe.dll`CopyMem(DestinationBuffer=3D= 0x000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at Cop= yMemWrapper.c:47 > (lldb) finish > error: Could not create return address breakpoint. > (lldb) n > Process 1 stopped > * thread #1, stop reason =3D step over > frame #0: 0x000000007e5c13ce MnpDxe.dll`CopyMem(DestinationBuffer=3D= 0x000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at Cop= yMemWrapper.c:50 > 47 if (Length =3D=3D 0) { > 48 return DestinationBuffer; > 49 } > -> 50 ASSERT ((Length - 1) <=3D (MAX_ADDRESS - (UINTN)DestinationB= uffer)); > 51 ASSERT ((Length - 1) <=3D (MAX_ADDRESS - (UINTN)SourceBuffe= r)); > 52 > 53 if (DestinationBuffer =3D=3D SourceBuffer) { > (lldb) > ... > Process 1 stopped > * thread #1, stop reason =3D step over > frame #0: 0x000000007e5c14b4 MnpDxe.dll`CopyMem(DestinationBuffer=3D= 0x000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at Cop= yMemWrapper.c:57 > 54 return DestinationBuffer; > 55 } > 56 return InternalMemCopyMem (DestinationBuffer, SourceBuffer,= Length); > -> 57 } > (lldb) > Process 1 stopped > * thread #1, stop reason =3D step over > frame #0: 0x000000007e5c726e MnpDxe.dll > -> 0x7e5c726e: mov rax, qword ptr [rsp + 0x60] > 0x7e5c7273: cmp byte ptr [rax + 0x68], 0x0 > 0x7e5c7277: jne 0x7e5c7291 > 0x7e5c727d: movabs rax, -0x7fffffffffffffed > (lldb) bt > * thread #1, stop reason =3D step over > * frame #0: 0x000000007e5c726e MnpDxe.dll >=20 > =E2=80=94=E2=80=94=E2=80=94 >=20 > (lldb) c > Process 1 resuming > Process 1 stopped > * thread #1, stop reason =3D signal SIGINT > frame #0: 0x000000007fe4d72e DxeCore.dll > -> 0x7fe4d72e: cmp al, 0x0 > 0x7fe4d730: je 0x7fe4d765 > 0x7fe4d736: mov rcx, qword ptr [rsp + 0x20] > 0x7fe4d73b: call 0x7fe4c4b0 > (lldb) bt > * thread #1, stop reason =3D signal SIGINT > * frame #0: 0x000000007fe4d72e DxeCore.dll >=20 > On macOS the Mach-O and dSYM have a UUID (dwarfdump -u) that is indexed = by Spotlight (mdfind "com_apple_xcode_dsym_uuids =3D=3D *") [2] > This should be the UUID in the debug directory entry and you can use tha= t to lookup the symbols like this: >=20 > module =3D target.AddModule (None, None, uuid) > SBError =3D target.SetModuleLoadAddress (module, LoadAddress + TeAdjust) >=20 > Also lldb has built in help for commands, but it is kind of terse since = it is autogenerated from the C++ swig. > (lldb) script help (lldb.target.AddModule) > Help on method AddModule in module lldb: >=20 > AddModule(self, *args) method of lldb.SBTarget instance > AddModule(SBTarget self, SBModule module) -> bool > AddModule(SBTarget self, char const * path, char const * triple, cha= r const * uuid) -> SBModule > AddModule(SBTarget self, char const * path, char const * triple, cha= r const * uuid_cstr, char const * symfile) -> SBModule > AddModule(SBTarget self, SBModuleSpec module_spec) -> SBModule >=20 >=20 > The minimum you need to symbolicate a frame is uuid, LoadAddress, and P= C. >=20 > [1] http://lldb.llvm.org/use/map.html > [2] http://lldb.llvm.org/use/symbols.html >=20 > Thanks for the links again. Yes, I am using some of these, and in fact f= or GDB that=E2=80=99s pretty much what I did when I worked with XCODE5. It = is very likely that when I get to complete LLDB support for XCODE5 it will = work quite fine too. But I am already happy with XCODE5 here, and making it= even better will only help myself, but not other people with e.g. Linux or= people that want me to use the same compiler with them. >=20 >=20 > Thanks for looking out for others. >=20 > Thanks, >=20 > Andrew Fish >=20 >=20 > Best regards, > Vitaly >=20 >=20 > 21 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0=B2 20:13, Andrew Fis= h > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= = =D0=B0=D0=BB(=D0=B0): >=20 >=20 >=20 >=20 > On Mar 21, 2020, at 3:28 AM, Vitaly Cheptsov > wrote: >=20 > Hello, >=20 > Andrey, thanks for the hint, it was very helpful. I rewrote the GDB scri= pts to work with LLDB[1] and was able to debug OVMF built with CLANGPDB. Wh= ile it is still quite dirty, at the very least it works. >=20 > Unfortunately the experience was close to terrible. I may certainly do s= omething wrong, but it is clear that PDB and LLDB do not support each other= well enough. After spending several hours on playing with the tools my con= clusion is that LLDB is simply not suited for UEFI PDB debugging, and we re= ally want DWARF as there is no other opensource debugger that supports PDB= on macOS and Linux >=20 > In case somebody knows workarounds here are the issues I faced: >=20 > 1. All integer alias typedefs are discarded in favour of underlying type= s. This way EFI_STATUS and EFI_TPL become unsigned long long, CHAR8 becomes= char, and CHAR16 becomes unsigned short. It does not look like LLDB has th= e original types anywhere at all, and it also does not have them registered= . >=20 > frame #0: 0x000000007fe242aa DxeCore.dll`CoreAllocatePoolPagesI(Pool= Type=3DEfiBootServicesData, NoPages=3D1, Granularity=3D4096, NeedGuard=3D'\= 0') at Pool.c:322 > 319 return NULL; > 320 } > 321 > -> 322 Buffer =3D CoreAllocatePoolPages (PoolType, NoPages, Gra= nularity, NeedGuard); > 323 CoreReleaseMemoryLock (); > 324 > 325 if (Buffer !=3D NULL) { > (lldb) p Status > (unsigned long long) $3 =3D 0 >=20 > Structures work more or less fine, but for simpler types like strings we= are out of even potential pretty-printing. >=20 >=20 > Vitaly, >=20 > You can teach lldb about types. There is some example code here: https:/= /github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py >=20 >=20 > 2. Global variables are not accessible. I am not sure what happens, but = they either seem to not relocate or conflict with the other names: >=20 > (lldb) p gST > error: Couldn't materialize: couldn't get the value of variable ::gST: r= ead memory from 0x6e18 failed > error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression > (lldb) p &gST > error: Couldn't materialize: couldn't get the value of variable ::gST: r= ead memory from 0x6e18 failed > error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression >=20 >=20 > That is strange as globals usually work best? The common issue I've seen= is getting the slide wrong. The EFI modules are linked at a value near zer= o and relocated into memory, so the slide represents that adjustment. >=20 > You can use `image dump sections` and ` image dump symtab` to see lldb's= view of symbols. More info here [1]. >=20 >=20 > 3. Quite a number of crashes. >=20 > In most cases autocompletion by tab press causes a crash. E.g. >=20 > b I >=20 > So will do printing of a GUID, e.g. p gEfiGlobalVariableGuid. >=20 > This may have to do with Python compatibility as Xcode 11 LLDB that uses= Python 3 generally crashes more often than MacPorts LLDB 9.0. Surprisingly= structures work more or less fine. >=20 >=20 > You can tell lldb to use the older Python like this (from the Terminal.a= pp): > $ defaults write com.apple.dt.lldb DefaultPythonVersion 2 >=20 >=20 > 4. Ctrl+C does not produce a valid backtrace. When I break with a breakp= oint, I see a proper stacktrace with more than one entry, with function pro= totypes and values. When I break with Ctrl+C I only see some weird backtrac= e with most of the entries missing regardless of frame position: >=20 > (lldb) bt > * thread #1, stop reason =3D signal SIGTRAP > * frame #0: 0x000000007fe4c5f3 DxeCore.dll >=20 > Probably more and all the unintuitive stuff like the lack of more functi= onal TUI, but it is hard to remember all the trials. >=20 >=20 > For the macOS API clang emits frame pointers, so you can walk the stack = without symbols. You could try adding the compiler flag to emit the frame p= ointers. >=20 >=20 > [1] https://github.com/acidanthera/OpenCorePkg/blob/master/Debug/Scripts= /lldb_uefi.py >=20 >=20 > On macOS the Mach-O and dSYM have a UUID (dwarfdump -u) that is indexed = by Spotlight (mdfind "com_apple_xcode_dsym_uuids =3D=3D *") [2] > This should be the UUID in the debug directory entry and you can use tha= t to lookup the symbols like this: >=20 > module =3D target.AddModule (None, None, uuid) > SBError =3D target.SetModuleLoadAddress (module, LoadAddress + TeAdjust) >=20 > Also lldb has built in help for commands, but it is kind of terse since = it is autogenerated from the C++ swig. > (lldb) script help (lldb.target.AddModule) > Help on method AddModule in module lldb: >=20 > AddModule(self, *args) method of lldb.SBTarget instance > AddModule(SBTarget self, SBModule module) -> bool > AddModule(SBTarget self, char const * path, char const * triple, cha= r const * uuid) -> SBModule > AddModule(SBTarget self, char const * path, char const * triple, cha= r const * uuid_cstr, char const * symfile) -> SBModule > AddModule(SBTarget self, SBModuleSpec module_spec) -> SBModule >=20 >=20 > The minimum you need to symbolicate a frame is uuid, LoadAddress, and P= C. >=20 > [1] http://lldb.llvm.org/use/map.html > [2] http://lldb.llvm.org/use/symbols.html >=20 > Thanks, >=20 > Andrew Fish >=20 >=20 >=20 > Best wishes, > Vitaly >=20 > 20 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0=B2 22:14, Andrew Fis= h > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= = =D0=B0=D0=BB(=D0=B0): >=20 >=20 >=20 >=20 > On Mar 20, 2020, at 8:13 AM, Vitaly Cheptsov > wrote: >=20 > Hello, >=20 > We noticed that the original bugzilla, which intended to add new LLVM to= olchain support[1], also wanted to bring ELF format support with DWARF debu= gging information. For some reason this did not make its way into EDK II, a= nd we are currently wondering, how can one debug binaries built with LLVM 9= .0. >=20 >=20 > For macOS and XCODE5 toolchain we use GDB scripts based on Andrei Warken= tin=E2=80=99s work, which allow us to integrate with QEMU and VMware[2]. It= is likely that they should work with little to no work on Linux with CLANG= 38/GCC5 with GDB once again. However, CLANGPDB apparently is using PDB debu= gging information, which I believe is not handled with GDB. >=20 > Could you please provide the details on the matter and let us know about= the recommended route? > =E2=80=94 Is dropping CLANGELF just a temporary measure and it should be= resubmitted again? > =E2=80=94 Should LLDB, which seems to be aware of PDB, be used instead o= f GDB, when building with CLANGPDB? If so, did anybody try that? >=20 >=20 >=20 > Vitaly, >=20 > I've not tried the CLANGPDB path, but if you want to connect lldb to QEM= U you need to set plugin.process.gdb-remote.target-definition-file [1] to = [2]. >=20 > [1] lldb -o "settings set plugin.process.gdb-remote.target-definition-f= ile x86_64_target_definition.py" -o "gdb-remote 9000" > [2] https://github.com/llvm-mirror/lldb/blob/master/examples/python/x86_= 64_target_definition.py >=20 > Thanks, >=20 > Andrew Fish >=20 >=20 > Thanks! >=20 >=20 > Best regards, > Vitaly >=20 > [1] https://bugzilla.tianocore.org/show_bug.cgi?id=3D1603 > [2] https://github.com/acidanthera/OpenCorePkg/blob/master/Debug/Scripts= /gdb_uefi.py >=20 >=20 >=20 > >=20 >=20 --Apple-Mail=_20A622B7-7708-4A3C-BA59-ACC83EE9DCEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Liming,
The issue with CLANG38 is that it uses L= D BFD, a GNU linker, which is not distributed with LLVM. This makes CLANG38= to be unusable on e.g. macOS or other BSD systems, where GNU linker is not= used. Making CLANG38 somehow work with LLD (e.g. by somehow providing it a= n environment variable to use ld.lld) should most likely solve the issue, b= ut I am not positive how to address it best.

Best regards,
Vitaly

25 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0=B2 16:16, Gao, = Liming <liming.gao@in= tel.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
= Vitaly:
 Tha= nks for your further investigation with LLDB. Now, we have two CLANG tool c= hain. CLANGPDB and CLANG38. CLANGPDB works with LLVM9.0 or above to generat= e PE image with PDB debug symbol. CLANG38 can also be used to generate ELF = image and convert to PE image with DWARF debug symbol on Linux host. So, th= ese two chains cover both usage models. We don=E2=80=99t need to introduce = new CLANGDWARF tool chain. For LLDB issue on PDB debug symbol, I suggest to= report them in LLVM. 
=  
 Besides, LLVM10.0 is= just released.
=  
Thanks
Liming
F= rom:&nbs= p;devel@edk2.groups.io <devel@ed= k2.groups.io> On Behalf Of Vitaly Cheptsov
Sent: 2020=E5=B9=B43=E6=9C=8823=E6=97=A5 17:10
To: Andrew Fish &l= t;afish@apple.com>; Gao, Liming <liming.gao@intel.com>
C= c: devel@edk2.groups.io; Marvin H=C3=A4user <mhaeuser@outlook.de>
Subject: Re: [edk2-devel] CLANG= PDB binary debugging
 <= /div>
Andrew,=
 
I investigated further and was ab= le to make some progress. I got rid of PDB, and changed debug information g= eneration to DWARF[1]. This resolved most of LLDB crashes and made pretty-p= rinting work just fine as type aliases like EFI_STATUS now work correctly (= I am still to commit this). Unfortunately there are several downsides. Dead= code stripping in LLD linker is broken when generating PE with DWARF, so I= had to patch it[2]. Debug link implementation in llvm-objcopy is also quit= e ugly, we do not get MTOC or anything alike[3], just some section with a r= andom name containing base filename.
 
I can submit a more proper patch to EDK II proper= ly implementing CLANGDWARF toolchain instead of patching CLANGPDB like in [= 1], but it is questionable whether it is worth it. LLVM 10 will land very s= oon, and the necessary LLD patches[2] will definitely not make their way in= this release. We will have to wait for LLVM 11 at the very least, and I am= not sure I am ready to drive llvm-objcopy changes either. Liming, what do = you think?
 <= /div>
I've not used the fake image to get things done so I can't speak = to that. I have used a fake target so I could have XIP PEIM and shadowed PE= IM address available at the same time. You can't have a module loaded at 2 = addresses at the same time in llldb. But you might be able to use a fake ta= rget for your fake stuff?
 = ;
Just in case:
&nb= sp;
=           # create= a faka target to store info about symbols
&nbs= p;         PeiXipTarget =3D target.debugger.CreateTarge= t (None, "i386-apple-macosx", "remote-macosx", True, error)=
 
       =   # make sure the gdb-remote  connection target is the active ta= rget
          target.= debugger.SetSelectedTarget (target)
 
Yes, that was actually a smart idea. I initially= did it that way, as I had mixing Mach-O and PE triples, but later removed,= which was actually a mistake. Now I have a fake target for GdbSyms and a p= roper target for other images[4]. This somewhat solves the issue with inval= id addresses for gST, as gST from DxeCore is now picked. However, I cannot = access global variables from other modules for some reason still.
 
If yo= u want to inspect globals I think this logic works to get you data, you wou= ld need to print it out etc. 
=
 
SBValueList =3D lldb.target.FindGlobalVariables (= "gST", 1024)
for SBValue in SBValueList:
Module =3D SBValue.GetAddress().GetModule() 
        ModuleStr =3D SBValu= e.GetAddress().GetModule().GetFileSpec().GetFilename()
        Start =3D int (SBValue.GetLocation(), 0= )
        End =3D Start + S= BValue.GetByteSize() - 1
      =   SBDeclaration =3D SBValue.GetDeclaration()
&nbs= p;       Column =3D SBDeclaration= .GetColumn()
 
I wrote a command in the early da= ys to dump out all the instances of a global. 
 
You can also try (lldb) image loo= kup -Av --name gST
 
Something is really weird, gST from the first ima= ge shows, but lldb believes that it does not exist. lldb.target.FindGlobalVariables ("gST", 1024) also returns an emp= ty list.
 
I noticed that LLDB shows invalid type for gST in the symtab, there = also is no address. I started to wonder whether this is the cause and decid= ed to check XCODE5, as the the issue could have been with PE format. Unfort= unately even after I tried XCODE5 support = with LLDB, I got exactly the same problem. I am quite clueless what is goin= g on. Below I included two transcripts: for CLANGDWARF and XCODE5.
=  
(lldb)&n= bsp;p gST
(EFI_SYSTEM_TABLE *) $0 =3D 0x000000007f9ee018
(lldb) p *gST
(EFI_SYSTEM_TABLE)= $1 =3D {
  Hdr =3D (Signature =3D 0x54535953204942= 49, Revision =3D 0x00020046, HeaderSize =3D 0x00000078, CRC32 =3D 0x3d5e9b5= d, Reserved =3D 0x00000000)
  FirmwareVendor =3D 0x= 000000007f9e9c98
  FirmwareRevision =3D 0x00010000<= br class=3D"">  ConsoleInHandle =3D 0x000000007ed58f18
  ConIn =3D 0x000000007e6edcb8
  C= onsoleOutHandle =3D 0x000000007ed57018
  ConOut =3D= 0x000000007e6ede40
  StandardErrorHandle =3D 0x000= 000007ed57a98
  StdErr =3D 0x000000007e6ee030
  RuntimeServices =3D 0x000000007f9eeb98
&= nbsp; BootServices =3D 0x000000007fe689e8
  Nu= mberOfTableEntries =3D 0x000000000000000a
  Configu= rationTable =3D 0x000000007f9eec98
}
(lldb)&nbs= p;image lookup -Av --name gST
(lldb) image dump sections=
Dumping sections for 90 modules.
Sections for = '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_CLANGPDB/X64/DxeCo= re.debug' (x86_64):
  SectID    &nbs= p;Type             Load Address&nbs= p;                    &nb= sp;       Perm File Off.  File Size &nbs= p;Flags      Section Name
  ---= ------- ---------------- ---------------------------------------  = ;---- ---------- ---------- ---------- ----------------------------
  0xffffffffffffffff container       &= nbsp;[0x000000007fe1b000-0x000000007ff38ac0)  ---  0x00= 000000 0x00000000 0x00000000 DxeCore.debug.
  0x000= 00001 code             [0x000000007= fe1b320-0x000000007fe61f34)  ---  0x00000320 0x00046c20= 0x60000020 DxeCore.debug...text
  0x00000002 data&= nbsp;            [0x000000007fe61f40-0x0= 00000007fe680f1)  ---  0x00046f40 0x000061c0 0x40000040= DxeCore.debug...rdata
  0x00000003 data  = ;           [0x000000007fe68100-0x000000007fe= 6d1e0)  ---  0x0004d100 0x000018a0 0xc0000040 DxeCore.d= ebug...data
  0x00000004 regular     = ;     [0x000000007fe6d1e0-0x000000007fe6d424)  ---=   0x0004e9a0 0x00000260 0x42000040 DxeCore.debug...reloc
  0x00000005 dwarf-abbrev     [0x00000= 0007fe6d440-0x000000007fe74059)  ---  0x0004ec00 0x0000= 6c20 0x42000040 DxeCore.debug...debug_abbrev
  0x00= 000006 dwarf-info       [0x000000007fe74060-0x0000= 00007fec1355)  ---  0x00055820 0x0004d300 0x42000040 Dx= eCore.debug...debug_info
  0x00000007 dwarf-line&nb= sp;      [0x000000007fec1360-0x000000007fef9fd4) &= nbsp;---  0x000a2b20 0x00038c80 0x42000040 DxeCore.debug...debug_= line
  0x00000008 dwarf-macinfo    [= 0x000000007fef9fe0-0x000000007fefa056)  ---  0x000db7a0= 0x00000080 0x42000040 DxeCore.debug...debug_macinfo
 &n= bsp;0x00000009 dwarf-ranges     [0x000000007fefa060-0x0= 00000007feff610)  ---  0x000db820 0x000055c0 0x42000040= DxeCore.debug...debug_ranges
  0x0000000a dwarf-st= r        [0x000000007feff620-0x000000007ff38abd)&n= bsp; ---  0x000e0de0 0x000394a0 0x42000040 DxeCore.debug...d= ebug_str
Sections for '/Users/user/Documents/UefiWorkspace/Bu= ild/OvmfX64/NOOPT_CLANGPDB/X64/DevicePathDxe.debug' (x86_64):
  SectID     Type       =       Load Address         &nb= sp;                   Per= m File Off.  File Size  Flags      = Section Name
  ---------- ---------------- --------= -------------------------------  ---- ---------- ---------- -----= ----- ----------------------------
  0xffffffffffff= ffff container        [0x000000007f986000-0x000000= 007f9cb0a0)  ---  0x00000000 0x00000000 0x00000000 Devi= cePathDxe.debug.
  0x00000001 code   &nbs= p;         [0x000000007f986320-0x000000007f996dc6)=   ---  0x00000320 0x00010ac0 0x60000020 DevicePathDxe.d= ebug...text
  0x00000002 data     &n= bsp;       [0x000000007f996de0-0x000000007f999b75) = ; ---  0x00010de0 0x00002da0 0x40000040 DevicePathDxe.debug.= ..rdata
  0x00000003 data      =       [0x000000007f999b80-0x000000007f99a202) &nb= sp;---  0x00013b80 0x00000660 0xc0000040 DevicePathDxe.debug...da= ta
  0x00000004 regular        =   [0x000000007f99a220-0x000000007f99a464)  --- &nb= sp;0x000141e0 0x00000260 0x42000040 DevicePathDxe.debug...reloc
  0x00000005 dwarf-abbrev     [0x000000007= f99a480-0x000000007f99bd09)  ---  0x00014440 0x000018a0= 0x42000040 DevicePathDxe.debug...debug_abbrev
  0x= 00000006 dwarf-info       [0x000000007f99bd20-0x00= 0000007f9ad8b7)  ---  0x00015ce0 0x00011ba0 0x42000040 = DevicePathDxe.debug...debug_info
  0x00000007 dwarf= -line       [0x000000007f9ad8c0-0x000000007f9bc1f7= )  ---  0x00027880 0x0000e940 0x42000040 DevicePathDxe.= debug...debug_line
  0x00000008 dwarf-macinfo =   [0x000000007f9bc200-0x000000007f9bc223)  --- &n= bsp;0x000361c0 0x00000040 0x42000040 DevicePathDxe.debug...debug_macinfo  0x00000009 dwarf-ranges     [0x= 000000007f9bc240-0x000000007f9be020)  ---  0x00036200 0= x00001de0 0x42000040 DevicePathDxe.debug...debug_ranges
 = ; 0x0000000a dwarf-str        [0x000000007f9b= e020-0x000000007f9cb099)  ---  0x00037fe0 0x0000d080 0x= 42000040 DevicePathDxe.debug...debug_str
=
=E2=80= = =A6
(lldb) image dump symtab
Dumping symbol table for 90 modules.
Symtab, file =3D /User= s/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_CLANGPDB/X64/DxeCore.deb= ug, num_symbols =3D 4343:
          =      Debug symbol
        =        |Synthetic symbol
    &n= bsp;          ||Externally Visible
&= nbsp;              |||
Ind= ex   UserID DSX Type           = ; File Address/Value Load Address       Size&= nbsp;              Flags  &nbs= p;   Name
------- ------ --- --------------- ------= ------------ ------------------ ------------------ ---------- -------------= ---------------------
[    0] 4294967295 =     Invalid         0x00000000= 00000000 0x000000007fe1b000 0x000000000000003a 0x00000000 .text
[    1] 4294967295     Invalid &= nbsp;       0x0000000000000000      &nbs= p;             0x0000000000000000 0x0000= 0000 .data
[    2] 4294967295   &nbs= p; Invalid         0x0000000000001898&nb= sp;                   0x0= 000000000000000 0x00000000 .bss
[    3] 429496= 7295     Invalid         = 0x0000000000046bc0 0x000000007fe61bc0 0x0000000000000374 0x00000000 .text$_= ModuleEntryPoint
[    4] 4294967295  = ;   Code            0x00000000= 00046bc0 0x000000007fe61bc0 0x0000000000000374 0x00000000 _ModuleEntryPoint=
[    5] 4294967295     In= valid         0x0000000000001b08   =                 0x00000000000= 00000 0x00000000 .bss$gHobList
[    6] 4294967= 295     Invalid         0= x0000000000001b08                &n= bsp;   0x0000000000000000 0x00000000 gHobList
[&nbs= p;   7] 4294967295     Invalid   &n= bsp;     0x0000000000000000         = ;           0x0000000000000000 0x00000000 .rd= ata
[    8] 4294967295     = ;Invalid         0x0000000000000000  &nb= sp;                 0x00000000= 00000000 0x00000000 .str
[    9] 4294967295&nb= sp;    Invalid         0x00000= 00000000058                  &= nbsp; 0x0000000000000000 0x00000000 .rdata
[  =  10] 4294967295     Invalid     &nb= sp;   0x0000000000000058           =         0x0000000000000000 0x00000000 .str.1
[   11] 4294967295     Invalid=          0x0000000000000000    &nbs= p;               0x0000000000000000= 0x00000000 .debug_str
[   12] 4294967295 = ;    Invalid         0x0000000= 000000000                  &nb= sp; 0x0000000000000000 0x00000000 .debug_abbrev
[ &= nbsp; 13] 4294967295     Invalid    = ;     0x0000000000000000          &= nbsp;         0x0000000000000000 0x00000000 .debug= _info
[   14] 4294967295    &nb= sp;Invalid         0x0000000000000000  &= nbsp;                 0x000000= 0000000000 0x00000000 .debug_ranges
[   15] 42= 94967295     Invalid        &n= bsp;0x0000000000000000              &nbs= p;     0x0000000000000000 0x00000000 .debug_macinfo
[   16] 4294967295     Invalid&nb= sp;        0x0000000000000000      =               0x0000000000000000 0x= 00000000 .debug_line
[   17] 4294967295 &= nbsp;   Code            0x0000= 00000003f680 0x000000007fe5a680 0x0000000000000020 0x00000000 ProcessModule= EntryPointList
[   18] 4294967295   =   Code            0x0000000000= 023130 0x000000007fe3e130 0x0000000000000020 0x00000000 DebugAssertEnabled<= br class=3D"">[   19] 4294967295     Cod= e            0x0000000000023060 0x000000= 007fe3e060 0x00000000000000d0 0x00000000 DebugAssert
[ &= nbsp; 20] 4294967295     Code      =       0x0000000000022150 0x000000007fe3d150 0x000000000= 0000020 0x00000000 CpuDeadLoop
[   21] 4294967= 295     Invalid         0= x0000000000000000 0x000000007fe1b000 0x000000000000003a 0x00000000 .text[   22] 4294967295     Inval= id         0x0000000000000000    &n= bsp;               0x00000000000000= 00 0x00000000 .data
[   23] 4294967295 &n= bsp;   Invalid         0x0000000000= 001898                   =  0x0000000000000000 0x00000000 .bss
[   2= 4] 4294967295     Invalid       &nb= sp; 0x000000000003f240 0x000000007fe5a240 0x0000000000000440 0x0000000= 0 .text$ProcessLibraryConstructorList
[   25] = 4294967295     Code          &= nbsp; 0x000000000003f240 0x000000007fe5a240 0x0000000000000440 0x00000= 000 ProcessLibraryConstructorList
[   26] 4294= 967295     Invalid        &nbs= p;0x000000000003f680 0x000000007fe5a680 0x0000000000000020 0x00000000 .text= $ProcessModuleEntryPointList
[   27] 429496729= 5     Invalid         0x0= 000000000000070                &nbs= p;   0x0000000000000000 0x00000000 .data$gEfiCallerIdGuid
[   28] 4294967295     Invalid&nb= sp;        0x0000000000000070      =               0x0000000000000000 0x= 00000000 gEfiCallerIdGuid
[   29] 4294967295&n= bsp;    Invalid         0x0000= 000000000148                  =   0x0000000000000000 0x00000000 .data$gEfiEventMemoryMapChangeGui= d
[   30] 4294967295     I= nvalid         0x0000000000000148   = ;                 0x0000000000= 000000 0x00000000 gEfiEventMemoryMapChangeGuid
[  &= nbsp;31] 4294967295     Invalid     &nbs= p;   0x0000000000000168            =         0x0000000000000000 0x00000000 .data$gEfiEv= entVirtualAddressChangeGuid
[   32] 4294967295=      Invalid         0x00= 00000000000168                 = ;   0x0000000000000000 0x00000000 gEfiEventVirtualAddressChangeGu= id
[   33] 4294967295     = Invalid         0x0000000000000138  &nbs= p;                 0x000000000= 0000000 0x00000000 .data$gEfiEventExitBootServicesGuid
[ = ;  34] 4294967295     Invalid   &nb= sp;     0x0000000000000138         =           0x0000000000000000 0x00000000 gEfi= EventExitBootServicesGuid
=E2=80=A6.
[  303] 4294967295     Invalid &n= bsp;       0x0000000000001b60       = ;             0x0000000000000000 0x00000= 000 .bss$gST
[  304] 4294967295    &= nbsp;Invalid         0x0000000000001b60 =                   0x0000= 000000000000 0x00000000 gST
[  305] 4294967295 = ;    Invalid         0x0000000= 0000018a0                  &nb= sp; 0x0000000000000000 0x00000000 .bss$gBS
[  = 306] 4294967295     Invalid       &= nbsp; 0x00000000000018a0            &nbs= p;       0x0000000000000000 0x00000000 gBS
=E2=80=A6
 =
= = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
 
(lldb) p gST=
(EFI_SYSTEM_TABLE *) $2 =3D 0x000000007fbee018
(lldb) p &gST
(EFI_SYSTEM_= TABLE **) $4 =3D 0x000000007fe6d788
(lldb) p *gST
(EFI_SYSTEM_TABLE) $3 =3D {<= br class=3D"">  Hdr =3D (Signature =3D 0x5453595320494249, Revisi= on =3D 0x00020046, HeaderSize =3D 0x00000078, CRC32 =3D 0x5355dbe2, Reserve= d =3D 0x00000000)
  FirmwareVendor =3D 0x000000007f= be9c98
  FirmwareRevision =3D 0x00010000
  ConsoleInHandle =3D 0x000000007ede5a98
&nb= sp; ConIn =3D 0x000000007e95f640
  ConsoleOutH= andle =3D 0x000000007ede4e98
  ConOut =3D 0x0000000= 07e95f800
  StandardErrorHandle =3D 0x000000007ede4= b98
  StdErr =3D 0x000000007e95f910
&= nbsp; RuntimeServices =3D 0x000000007fbeeb98
  = ;BootServices =3D 0x000000007fe6cde8
  NumberOfTabl= eEntries =3D 0x0000000000000009
  ConfigurationTabl= e =3D 0x000000007fbeec98
}
(lldb) image lo= okup -Av --name gST
(lldb) image dump sections
Dumping sections for 88 modules.
Sections for '/Users/= user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_XCODE5/X64/MdeModulePkg/Co= re/Dxe/DxeMain/DEBUG/DxeCore.dll' (x86_64):
  SectI= D     Type           &nbs= p; Load Address               =               Perm File Off. &= nbsp;File Size  Flags      Section Name
  ---------- ---------------- --------------------------= -------------  ---- ---------- ---------- ---------- ------------= ----------------
  0x00000100 container   = ;     [0x000000007fe26240-0x000000007fe6bb40)  r-x=   0x000004a0 0x00045900 0x00000000 DxeCore.dll.__TEXT
  0x00000001 code           &nbs= p; [0x000000007fe26240-0x000000007fe65bd8)  r-x  0= x000004a0 0x0003f998 0x80000400 DxeCore.dll.__TEXT.__text
&nb= sp; 0x00000002 data-cstr        [0x000000007f= e65bd8-0x000000007fe6ba23)  r-x  0x0003fe38 0x00005e4b = 0x00000002 DxeCore.dll.__TEXT.__cstring
  0x0000000= 3 regular          [0x000000007fe6ba24-0x0000= 00007fe6ba6c)  r-x  0x00045c84 0x00000048 0x00000000 Dx= eCore.dll.__TEXT.__ustring
  0x00000004 regular&nbs= p;         [0x000000007fe6ba70-0x000000007fe6bb40)=   r-x  0x00045cd0 0x000000d0 0x00000000 DxeCore.dll.__T= EXT.__const
  0x00000200 container    &nb= sp;   [0x000000007fe6bb40-0x000000007fe70e60)  rw- = ; 0x00045da0 0x00001ae0 0x00000000 DxeCore.dll.__DATA
&n= bsp; 0x00000005 regular          [0x0000= 00007fe6bb40-0x000000007fe6bd58)  rw-  0x00045da0 0x000= 00218 0x00000000 DxeCore.dll.__DATA.__const
  0x000= 00006 data             [0x000000007= fe6bd60-0x000000007fe6d610)  rw-  0x00045fc0 0x000018b0= 0x00000000 DxeCore.dll.__DATA.__data
  0x00000007 = zero-fill        [0x000000007fe6d610-0x000000007fe= 70e20)  rw-  0x00000000 0x00000000 0x00000001 DxeCore.d= ll.__DATA.__common
  0x00000008 zero-fill  &nb= sp;     [0x000000007fe70e20-0x000000007fe70e58)  r= w-  0x00000000 0x00000000 0x00000001 DxeCore.dll.__DATA.__bss
  0x00000100 container        = ;[0x000000000004b000-0x00000000000ef000)* rw-  0x00001000 0x000a3= a74 0x00000000 DxeCore.dll.__DWARF
  0x00000001 dwa= rf-line       [0x000000000004b000-0x00000000000723= fb)* rw-  0x00001000 0x000273fb 0x00000000 DxeCore.dll.__DWARF.__= debug_line
  0x00000002 dwarf-pubnames  &= nbsp;[0x00000000000723fb-0x0000000000078429)* rw-  0x000283fb 0x0= 000602e 0x00000000 DxeCore.dll.__DWARF.__debug_pubnames
 = ; 0x00000003 dwarf-pubtypes   [0x0000000000078429-0x000= 000000008b915)* rw-  0x0002e429 0x000134ec 0x00000000 DxeCore.dll= .__DWARF.__debug_pubtypes
  0x00000004 dwarf-arange= s    [0x000000000008b915-0x000000000008ea65)* rw-  = ;0x00041915 0x00003150 0x00000000 DxeCore.dll.__DWARF.__debug_aranges
  0x00000005 dwarf-info       [= 0x000000000008ea65-0x00000000000c78bf)* rw-  0x00044a65 0x00038e5= a 0x00000000 DxeCore.dll.__DWARF.__debug_info
  0x0= 0000006 dwarf-frame      [0x00000000000c78bf-0x00000000= 000cc697)* rw-  0x0007d8bf 0x00004dd8 0x00000000 DxeCore.dll.__DW= ARF.__debug_frame
  0x00000007 dwarf-ranges &n= bsp;   [0x00000000000cc697-0x00000000000cc757)* rw-  0x= 00082697 0x000000c0 0x00000000 DxeCore.dll.__DWARF.__debug_ranges
  0x00000008 dwarf-abbrev     [0x00000= 000000cc757-0x00000000000cca9b)* rw-  0x00082757 0x00000344 0x000= 00000 DxeCore.dll.__DWARF.__debug_abbrev
  0x000000= 09 dwarf-str        [0x00000000000cca9b-0x00000000= 000dcc05)* rw-  0x00082a9b 0x0001016a 0x00000000 DxeCore.dll.__DW= ARF.__debug_str
  0x0000000a apple-names  &nbs= p;   [0x00000000000dcc05-0x00000000000e2439)* rw-  0x00= 092c05 0x00005834 0x00000000 DxeCore.dll.__DWARF.__apple_names
  0x0000000b apple-namespaces [0x00000000000e2439-0x00000000000= e245d)* rw-  0x00098439 0x00000024 0x00000000 DxeCore.dll.__DWARF= .__apple_namespac
  0x0000000c apple-types  &n= bsp;   [0x00000000000e245d-0x00000000000eea50)* rw-  0x= 0009845d 0x0000c5f3 0x00000000 DxeCore.dll.__DWARF.__apple_types
  0x0000000d apple-objc       [0x= 00000000000eea50-0x00000000000eea74)* rw-  0x000a4a50 0x00000024 = 0x00000000 DxeCore.dll.__DWARF.__apple_objc
Sections for '/Us= ers/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_XCODE5/X64/MdeModulePk= g/Universal/DevicePathDxe/DevicePathDxe/DEBUG/DevicePathDxe.dll' (x86_64):<= o:p class=3D"">
=E2=80=A6
(lldb)&nb= sp;image dump symtab
Dumping symbol table for 88 modules.
Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX= 64/NOOPT_XCODE5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll, num_sy= mbols =3D 1203:
            &nb= sp;  Debug symbol
          &nb= sp;    |Synthetic symbol
       = ;        ||Externally Visible
  &nbs= p;            |||
Index &n= bsp; UserID DSX Type            Fil= e Address/Value Load Address       Size  = ;             Flags     &= nbsp;Name
------- ------ --- --------------- ----------------= -- ------------------ ------------------ ---------- -----------------------= -----------
[    0]    118 D&nb= sp;  SourceFile      0x0000000000000000 =                   Siblin= g -> [   20] 0x00640000 /Users/user/Documents/UefiPa= ckages/MdeModulePkg/Core/Dxe/SectionExtraction/CoreSectionExtraction.c
[    1]    120 D   O= bjectFile      0x000000005e78588d      &= nbsp;             0x0000000000000000 0x0= 0660001 /Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_XCODE5= /X64/MdeModulePkg/Core/Dxe/DxeMain/OUTPUT/DxeCore.lib(CoreSectionExtraction= .obj)
[    2]    122 D X Code&n= bsp;           0x0000000000000240 0x000000007= fe26240 0x0000000000000260 0x000f0000 CustomGuidedSectionExtract
[    3]    126 D X Code    &= nbsp;       0x00000000000004a0 0x000000007fe264a0 0x000= 0000000000110 0x000f0000 InitializeSectionExtraction
[  =   4]    130 D X Code        &n= bsp;   0x00000000000005b0 0x000000007fe265b0 0x0000000000000140 0= x000f0000 IsValidSectionStream
[    5]  &= nbsp; 134 D X Code            0x000= 00000000006f0 0x000000007fe266f0 0x0000000000000180 0x000f0000 OpenSectionS= treamEx
[    6]    138 D X Code=             0x0000000000000870 0x0000000= 07fe26870 0x0000000000000070 0x000f0000 OpenSectionStream
[&n= bsp;   7]    142 D X Code      &nbs= p;     0x00000000000008e0 0x000000007fe268e0 0x0000000000000= 100 0x000f0000 ChildIsType
=E2=80=A6
[  831]   2470 D X Code     =       0x00000000000306b0 0x000000007fe566b0 0x00000000= 000000f4 0x000f0000 UefiBootServicesTableLibConstructor
[&nbs= p; 832]   2473 D X Data        &nbs= p;   0x0000000000047780 0x000000007fe6d780 0x0000000000000008 0x0= 00f0000 gImageHandle
[  833]   2474 = D X Data            0x0000000000047788 0= x000000007fe6d788 0x0000000000000008 0x000f0000 gST
[ &n= bsp;834]   2475 D X Data          &= nbsp; 0x0000000000047790 0x000000007fe6d790 0x0000000000000008 0x000f0= 000 gBS
=E2=80=A6
 
This is easy enough to chec= k as %rpb is the frame pointer so it will get saved/restored on function en= try/exit. 
 
Actually it is fine. I happened to break in the interrupt routine, which w= as not mapped for a particular image. After I stepped a little, it soon rea= ched the debug symbols:
 = ;
(lldb) bt all
* thread #1, stop reason =3D= instruction step over
  * frame #0: 0x000000007fe4= 9f3c DxeCore.dll`CoreRestoreTpl(NewTpl=3D0x0000000000000008) at Tpl.c:102:1= 2
    frame #1: 0x000000007e518c95
  thread #2
    frame #0: 0x00000= 0007fb3ff88 CpuDxe.dll`CpuSleep + 1
    frame = #1: 0x000000007fb4d719 CpuDxe.dll`ApWakeupFunction(ExchangeInfo=3D0x0000000= 000087198, ApIndex=3D0x0000000000000001) at MpLib.c:768:9
&nb= sp;   frame #2: 0x000000007fb2d151
  thre= ad #3
    frame #0: 0x000000007fb3ff88 CpuDxe.= dll`CpuSleep + 1
    frame #1: 0x000000007fb4d= 719 CpuDxe.dll`ApWakeupFunction(ExchangeInfo=3D0x0000000000087198, ApIndex= =3D0x0000000000000002) at MpLib.c:768:9
    f= rame #2: 0x000000007fb2d151
  thread #4
    frame #0: 0x000000007fb3ff88 CpuDxe.dll`CpuSleep + 1<= br class=3D"">    frame #1: 0x000000007fb4d719 CpuDxe.dll`Ap= WakeupFunction(ExchangeInfo=3D0x0000000000087198, ApIndex=3D0x0000000000000= 003) at MpLib.c:768:9
    frame #2: 0x00000000= 7fb2d151
 <= /div>
B= est wishes,
Vitaly=
=  
[1] https://github.com/acida= nthera/OpenCorePkg/blob/7684a9f/Debug/ClangDwarf.patch<= /o:p>
[2] https://b= ugs.llvm.org/show_bug.cgi?id=3D45273
=
[3]&nb= sp;https://bugs.llvm.org/show_= bug.cgi?id=3D45277
[4] https://github.com/acidanthera/OpenCorePkg/commit/3e5f3f3f9a8d3f197834bb= fcf5029f771df89754


=
22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0=B2 00= :06, Andrew Fish <afish@apple.com> =D0=BD= =D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):=
=  



=
On Mar 21, 2020, at 11:36 AM, Vitaly C= heptsov <cheptsov@ispras.ru> wrote:
 
Andrew,
 
=
Thanks once again, but un= fortunately it is not that simple. Below I answered inline explaining = the particular issues, which mostly seem to be specific to CLANGPDB. LLVM stack emits PDB debug= files, and even though LLDB does support them to some level, it is unlikel= y that this will be working well enough soon. We should really stick to mor= e or less native debug formats, ideally those that have proper open specifi= cations, on all platforms, and for Unix that=E2=80=99s DWARF.
 
 
Vitaly,
 
I understand and I use the Xcode clang a= nd not the CLANGPDB, but I use lldb a lot I was just trying to point out wh= at works with Xcode. 
 


I am pretty sure LLVM can be= taught to emit DWARF debug information even for PE files. Perhaps we can e= ither make some option or provide a separate toolchain for this? Another wa= y would be recovering CLANGELF as originally suggested.
 
 
= There was a bug recently in the  x86_64-pc-win32-macho triple and= we had to add -gdwarf to force it emit dwarf. Not sure what that comp= iler flag would do to CLANGPDB but it is worth a try? Last flag wins for th= e compiler. 
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: SimSun= ;" class=3D""> 
<= /div>


You can teach lldb= about types. There is some example code here: https://github.com/tianoc= ore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py<= /span>
 
This code works just fine with LLDB and DWARF (e.g. XCODE5), t= hough I have not yet completed these changes for my scripts for LLDB, only = for GDB. However, with CLANGPDB generated files it is not functional. The r= eason for this is because LLDB is unaware of the underlying type, i.e. it d= oes not know what is EFI_STATUS or UINT32. I can implement pretty-printing = when LLDB knows about a typedef, but it is not possible to do this when the= debug information is already gone or not parsed:
 
(lldb) p Status
(unsigned long long) $1 =3D 0(lldb) p &Status
(unsigned long long *) $2 = =3D 0x000000007fe19ad8
(lldb) p (EFI_STATUS)Status
error: use of undeclared identifier 'EFI_STATUS'
 
=
Just in case I tried using exactly your c= ode, and other stuff like source level debugging works just fine and symbol= ication works fine, so it should be some bug with PDB in particular.


=
That i= s strange as globals usually work best? The common issue I've seen is getti= ng the slide wrong. The EFI modules are linked at a value near zero and rel= ocated into memory, so the slide represents that adjustment. 
 
You can use `image dump sections` and `&nbs= p;image dump symtab` to see lldb's view of symbols. More info here [1].&nbs= p;
 
Yes, this one is a bit complicated, on= ce again due to PDB most likely. It knows about global symbols, but does no= t list them in symtab:
 
(lldb) = image dump symtab
Dumping symbol table for 91 modules.
Symtab, file =3D GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll, num_symbols = = =3D 0
Symtab, file =3D /Users/user/Documents/UefiWorkspace/B= uild/OvmfX64/NOOPT_CLANGPDB/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore= .dll, num_symbols =3D 0
Symtab, file =3D /Users/user/Document= s/UefiWorkspace/Build/OvmfX64/NOOPT_CLANGPDB/X64/MdeModulePkg/Universal/Dev= icePathDxe/DevicePathDxe/DEBUG/DevicePathDxe.dll, num_symbols =3D 0
=E2=80=A6
 
The slides are cor= rect, but there are two nuances that collide with it.=
 
1. There are multiple instances of the globals with the sam= e name (e.g. gBS), but for some reason LLDB always tries to print the globa= ls from the first module. This happens even when I am source-level debuggin= g, and I see a gBS symbol from another module (e.g. DxeCore) used right at = the same line. With GDB the closest symbol is used, but with LLDB it is alw= ays coming from the first module. I tried checking expr help to find whethe= r I can pass it a module explicitly, but also failed.=
 
 
Usually what= happens with lldb is you get the global that is in scope for the current f= rame. 


2.  To be able to get EFI types to locate = the EFI_SYSTEM_TABLE_POINTER I add a dummy GdbSyms image, which is not load= ed to the firmware. So basically I cannot slide what is not in the memory, = and this is also my first image. I tried deleting it anyhow, but it failed = for me.
 
 
I've not used the fake image to get things done so I ca= n't speak to that. I have used a fake target so I could have XIP PEIM and s= hadowed PEIM address available at the same time. You can't have a module lo= aded at 2 addresses at the same time in llldb. But you might be able to use= a fake target for your fake stuff?
 
Ju= st in case:
 
<= div class=3D"">
  &nb= sp;       # create a faka target to store info about symbols=
          PeiXipTarget =3D target.= debugger.CreateTarget (None, "i386-apple-macosx", "remote-macosx", True, er= ror)
 
         = ; # make sure the gdb-remote  connection target is the active target
          target.debugger.SetSelecte= dTarget (target)
 


(lldb) im= age dump sections
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: SimSun= ;" class=3D"">Dumping sections for 91 modules.
Sections for 'GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll' (x86_64):
  SectID     Type     =         Load Address       &nb= sp;                    &n= bsp;Perm File Off.  File Size  Flags     = ; Section Name
  ---------- ---------------- -= --------------------------------------  ---- ---------- ---------= - ---------- ----------------------------
  0xfffff= fffffffffff container        [0x0000000000000000-0= x0000000000006ec0)* ---  0x00000000 0x00000000 0x00000000 GdbSyms= .dll.
  0x00000001 code       &= nbsp;     [0x0000000000000220-0x0000000000005bd6)* --- =  0x00000220 0x000059c0 0x60000020 GdbSyms.dll...text
&nb= sp; 0x00000002 data            &nbs= p;[0x0000000000005be0-0x0000000000006d79)* ---  0x00005be0 0x0000= 11a0 0x40000040 GdbSyms.dll...rdata
  0x00000003 da= ta             [0x0000000000006d80-= 0x0000000000006e30)* ---  0x00006d80 0x00000060 0xc0000040 GdbSym= s.dll...data
  0x00000004 regular    &nbs= p;     [0x0000000000006e40-0x0000000000006ea4)* --- &nb= sp;0x00006de0 0x00000080 0x42000040 GdbSyms.dll...reloc
Secti= ons for '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_CLANGPDB/X= 64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll' (x86_64):
  SectID     Type       =       Load Address         &nb= sp;                   Per= m File Off.  File Size  Flags      = Section Name
  ---------- ---------------- --------= -------------------------------  ---- ---------- ---------- -----= ----- ----------------------------
  0xffffffffffff= ffff container        [0x0000000000000000-0x000000= 00000523a0)* ---  0x00000000 0x00000000 0x00000000 DxeCore.dll.  0x00000001 code         &= nbsp;   [0x000000007fe1b220-0x000000007fe61e34)  ---&nb= sp; 0x00000220 0x00046c20 0x60000020 DxeCore.dll...text
=   0x00000002 data            &= nbsp;[0x000000007fe61e40-0x000000007fe68065)  ---  0x00= 046e40 0x00006240 0x40000040 DxeCore.dll...rdata
  = 0x00000003 data             [0x0000= 00007fe68080-0x000000007fe6d160)  ---  0x0004d080 0x000= 018a0 0xc0000040 DxeCore.dll...data
  0x00000004 re= gular          [0x000000007fe6d160-0x00000000= 7fe6d398)  ---  0x0004e920 0x00000240 0x42000040 DxeCor= e.dll...reloc
Sections for '/Users/user/Documents/UefiWorkspa= ce/Build/OvmfX64/NOOPT_CLANGPDB/X64/MdeModulePkg/Universal/DevicePathDxe/De= vicePathDxe/DEBUG/DevicePathDxe.dll' (x86_64):
  Se= ctID     Type           &= nbsp; Load Address             &nbs= p;               Perm File Off.&nbs= p; File Size  Flags      Section Name  ---------- ---------------- -----------------------= ----------------  ---- ---------- ---------- ---------- ---------= -------------------
  0xffffffffffffffff container&= nbsp;       [0x0000000000000000-0x0000000000014420)* --= -  0x00000000 0x00000000 0x00000000 DevicePathDxe.dll.
  0x00000001 code           =   [0x000000007f986220-0x000000007f996cc6)  --- &nb= sp;0x00000220 0x00010ac0 0x60000020 DevicePathDxe.dll...text
=   0x00000002 data            &= nbsp;[0x000000007f996ce0-0x000000007f999b04)  ---  0x00= 010ce0 0x00002e40 0x40000040 DevicePathDxe.dll...rdata
 =  0x00000003 data             [= 0x000000007f999b20-0x000000007f99a1a2)  ---  0x00013b20= 0x00000660 0xc0000040 DevicePathDxe.dll...data
  0= x00000004 regular          [0x000000007f99a1c= 0-0x000000007f99a404)  ---  0x00014180 0x00000260 0x420= 00040 DevicePathDxe.dll=E2=80=A6reloc
=E2=80=A6
 
So, all in all, unique global variables work, but= there is no way to access duplicating variables. They either resolve to Gd= bSyms or just cause a crash:
 
(lldb)=  p mDebugInfoTableHeader
(EFI_DEBUG_IMAGE_INFO_TABLE_HEA= DER) $0 =3D {
  UpdateStatus =3D 2
&n= bsp; TableSize =3D 92
  EfiDebugImageInfoTable= =3D 0x000000007f814018
}
(lldb) p gBS
error: Couldn't materialize: couldn't get the value of variable = ::gBS: read memory from 0x6df8 failed
error: errored out in D= oExecute, couldn't PrepareToExecuteJITExpression
(lldb) = p gEfiGlobalVariableGuid
0  libLLVM.dylib  &nb= sp;         0x000000010e52ee68 llvm::sys::PrintSta= ckTrace(llvm::raw_ostream&) + 40
1  libLLVM.dyl= ib            0x000000010e52f262 SignalH= andler(int) + 188
2  libsystem_platform.dylib 0x000= 07fff6ca5642d _sigtramp + 29
...=
 
=
 
=
If you want to insp= ect globals I think this logic works to get you data, you would need to pri= nt it out etc. 
 
SBValueList =3D l= ldb.target.FindGlobalVariables ("gST", 1024)
for SBValue in = SBValueList:
   Module =3D SBValue.GetAddress().GetModule() 
&nb= sp;       ModuleStr =3D SBValue.GetAddress().GetModule().Get= FileSpec().GetFilename()
        Start = = =3D int (SBValue.GetLocation(), 0)
      &nb= sp; End =3D Start + SBValue.GetByteSize() - 1<= /div>
    =     SBDeclaration =3D SBValue.GetDeclaration()
      &n= bsp; Column =3D SBDeclaration.GetColumn()
=
 
=
I wrote a command i= n the early days to dump out all the instances of a global. 
 
You can also try (lldb) image lookup -Av --= name gST


You can tell lldb to use the older= Python like this (from the Terminal.app):
$ defaults w= rite com.apple.dt.lldb DefaultPythonVersion 2<= /div>
&= nbsp;
Thanks, that helped quite a bit, but for some reason Xcode version s= till crashes more for me. I attached a couple of stack traces if you feel l= ike having a look, but once again it seems that it is all about the PDB plu= gin.
 
For the macOS API clan= g emits frame pointers, so you can walk the stack without symbols. You coul= d try adding the compiler flag to emit the frame pointers. 
 
 
This is easy enough to check as %= rpb is the frame pointer so it will get saved/restored on function entry/ex= it. 


I am pretty sure stack frames a= re not disabled with UEFI, as sometimes backtracing works just fine. To me = it looks like debug information parsing randomly breaks in LLDB, and once i= t happens it forgets about other images:
=
&nb= sp;
(lldb) b CoreLocateHandleBuffer
Breakpoint 2: where = =3D DxeCore.dll`CoreLocateHandleBuffer + 31 at Locate.c:649, address =3D 0= x000000007fe36e4f
(lldb) c
Process 1 resum= ing
Process 1 stopped
* thread #1, stop reason = = =3D breakpoint 2.1
    frame #0: 0x= 000000007fe36e4f DxeCore.dll`CoreLocateHandleBuffer(SearchType=3DByPro= tocol, Protocol=3D0x000000007f978160, SearchKey=3D0x0000000000000000, Numbe= rHandles=3D0x000000007fe19fd8, Buffer=3D0x000000007fe19fc0) at Lo= cate.c:649
   646    &n= bsp; EFI_STATUS          Status;
   647      UINTN&nb= sp;              BufferSize;
   648    
->= ; 649     if (NumberHandles =3D=3D NU= LL) {
   650 &n= bsp;    =   return EFI_INVALID_PARAMETER;
   6= 51      }
   = 652    
(lldb) bt
* thread #1, stop reason =3D breakpoint 2.1
 = ; * frame #0: 0x000000007fe36e4f DxeCore.dll`CoreLocateHandl= eBuffer(SearchType=3DByProtocol, Protocol=3D0x000000007f978160, SearchKey= =3D0x0000000000000000, NumberHandles=3D0x000000007fe19fd8, Buffer=3D0= x000000007fe19fc0) at Locate.c:649
    fr= ame #1: 0x000000007fe36816 DxeCore.dll`CoreLocateDevicePath(Proto= col=3D0x000000007f978160, DevicePath=3D0x000000007fe1a060, Device=3D0x00000= 0007fe1a068) at Locate.c:466
    frame #2= : 0x000000007f97479a SecurityStubDxe.dll
 
=E2=80=94=E2=80=94=E2=80=94
=  
(lldb)&nbs= p;b CopyMem
Breakpoint 3: 70 locations.
(lldb)&= nbsp;c
Process 1 resuming
Process 1 stopped
* thread #1, stop reason =3D breakpoint 2.53 3.53
    frame #0: 0x000000007e5c13b3 MnpDxe.dll= `CopyMem(DestinationBuffer=3D0x000000007fe19b50, SourceBuffer=3D0x000000007= e2aa470, Length=3D656) at CopyMemWrapper.c:47
  &nb= sp;44        IN UINTN =       Length
   45  <= span class=3D"apple-tab-span">      )
   46&= nbsp;     {
-> 47 &n= bsp;     if (Length =3D=3D 0) {<= br class=3D"">   48  &nb= sp;   &n= bsp;   return DestinationBuffer;
   = 49        }
   50    &nbs= p;   ASS= ERT ((Length - 1) <=3D (MAX_ADDRESS - (UINTN)DestinationBuffer));(lldb) bt
* thread #1, stop reason =3D = ;breakpoint 2.53 3.53
  * frame #0: 0x00000000= 7e5c13b3 MnpDxe.dll`CopyMem(DestinationBuffer=3D0x000000007fe19b50, So= urceBuffer=3D0x000000007e2aa470, Length=3D656) at CopyMemWrapper.c:47<= br class=3D"">(lldb) finish
error: Could not create retu= rn address breakpoint.
(lldb) n
Process 1 = stopped
* thread #1, stop reason =3D step over
    frame #0: 0x000000007e5c13ce MnpDxe.dll= `CopyMem(DestinationBuffer=3D0x000000007fe19b50, SourceBuffer=3D0x000000007= e2aa470, Length=3D656) at CopyMemWrapper.c:50
  &nb= sp;47        if (Lengt= h =3D=3D 0) {
   48     &nb= sp;    return DestinationBuffer;
   49   &nbs= p;   &nb= sp;}
-> 50   = ;   &nbs= p;ASSERT ((Length - 1) <=3D (MAX_ADDRESS - (UINTN)DestinationBuffer= ));
   51        ASSERT ((Length - 1) <=3D (MAX_ADDRESS - (UINTN)Sourc= eBuffer));
   52      
   53        if (DestinationBuffer =3D=3D SourceBuffer) {
(lldb)  
...
Process 1 stopp= ed
* thread #1, stop reason =3D step over
=     frame #0: 0x000000007e5c14b4 MnpDxe.dll`CopyMe= m(DestinationBuffer=3D0x000000007fe19b50, SourceBuffer=3D0x000000007e2aa470= , Length=3D656) at CopyMemWrapper.c:57
   54&n= bsp;         return De= stinationBuffer;
   55      = ;  }
   56        return InternalMemCopyMem (Dest= inationBuffer, SourceBuffer, Length);
-> 57     }
(lldb)  
Pro= cess 1 stopped
* thread #1, stop reason =3D step over    frame #0: 0x000000007e5c726e MnpDx= e.dll
->  0x7e5c726e: mov    rax,= qword ptr [rsp + 0x60]
    0x7e5c7273: cmp&nb= sp;   byte ptr [rax + 0x68], 0x0
    = ;0x7e5c7277: jne    0x7e5c7291
   &n= bsp;0x7e5c727d: movabs rax, -0x7fffffffffffffed
(lldb) b= t
* thread #1, stop reason =3D step over=
 =  * frame #0: 0x000000007e5c726e MnpDxe.dll 
 
=E2=80=94=E2=80=94=E2=80=94
 
(lldb) c
Process 1 resumingProcess 1 stopped
* thread #1, stop reason =3D&nb= sp;signal SIGINT
    frame #0: 0x00000000= 7fe4d72e DxeCore.dll
->  0x7fe4d72e: cmp&nb= sp;   al, 0x0
    0x7fe4d730: je&nbs= p;    0x7fe4d765
    0x7fe4d736= : mov    rcx, qword ptr [rsp + 0x20]
  &n= bsp; 0x7fe4d73b: call   0x7fe4c4b0
(lldb)=  bt
* thread #1, stop reason =3D signal SIGINT
  * frame #0: 0x000000007fe4d72e DxeCore.dll<= o:p class=3D"">
 
On macOS the Mach-O and dSY= M have a UUID (dwarfdump -u) that is indexed by Spotlight (mdfind "com_appl= e_xcode_dsym_uuids =3D=3D *") [2]
<= div class=3D"">
This should be the UUID in= the debug directory entry and you can use that to lookup the symbols like = this:
 
module =3D target.AddModule (Non= e, None, uuid)
SBError =3D target.SetModuleLoadAddress (modu= le, LoadAddress + TeAdjust)
 
Also lldb = has built in help for commands, but it is kind of terse since it is autogen= erated from the C++ swig. 
(lldb) script help (lldb.target.AddModule)<= o:p class=3D"">
Help on method AddModule in module lldb:
&n= bsp;
Add= Module(self, *args) method of lldb.SBTarget instance<= /span>
   = AddModule(SBTarget self, SBModule module) -> bool=
   = AddModule(SBTarget self, char const * path, char const * triple, char cons= t * uuid) -> SBModule
    AddModule(SBTarget self, ch= ar const * path, char const * triple, char const * uuid_cstr, char const * = symfile) -> SBModule
    AddModule(SBTarget self, SB= ModuleSpec module_spec) -> SBModule


The minimum  you need to symbolicate a frame= is uuid, LoadAddress, and PC. 
&= nbsp;
[1] http://lldb.llvm.org/use/m= ap.html
<= /div>
 <= /o:p>
T= hanks for the links again. Yes, I am using some of these, and in fact for G= DB that=E2=80=99s pretty much what I did when I worked with XCODE5. It is v= ery likely that when I get to complete LLDB support for XCODE5 it will work= quite fine too. But I am already happy with XCODE5 here, and making it eve= n better will only help myself, but not other people with e.g. Linux or peo= ple that want me to use the same compiler with them.<= /span>
 
 
Thanks for l= ooking out for others. 
 
Thanks= ,
 
Andrew Fish<= /span>


Best r= egards,
Vitaly
 
 
21 =D0=BC=D0=B0=D1=80= =D1=82=D0=B0 2020 =D0=B3., =D0=B2 20:13, Andrew Fish <afish@apple.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(= =D0=B0):
 



On Mar 21, 2020= , at 3:28 AM, Vitaly Cheptsov <cheptsov@ispras.= ru> wrote:
 
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: SimSun= ;" class=3D"">Hello,
<= div class=3D"">
 
Andr= ey, thanks for the hint, it was very helpful. I rewrote the GDB scripts to = work with LLDB[1] and was able to debug OVMF built with CLANGPDB. While it = is still quite dirty, at the very least it works.
 
Unfortunately the experience was close to terrible. I may cert= ainly do something wrong, but it is clear that PDB and LLDB do not support = each other well enough. After spending several hours on playing with the to= ols my conclusion is that LLDB is simply not suited for UEFI PDB debugging,= and we really want DWARF  as there is no other opensource debugger th= at supports PDB on macOS and Linux
=
 
In = case somebody knows workarounds here are the issues I faced:
 
1. All integer alias typedefs are discarded in fa= vour of underlying types. This way EFI_STATUS and EFI_TPL become unsigned l= ong long, CHAR8 becomes char, and CHAR16 becomes unsigned short. It does no= t look like LLDB has the original types anywhere at all, and it also does n= ot have them registered.
 
   = ; frame #0: 0x000000007fe242aa DxeCore.dll`CoreAllocatePoolP= agesI(PoolType=3DEfiBootServicesData, NoPages=3D1, Granularity=3D4096, Need= Guard=3D'\0') at Pool.c:322
   319             return=  NULL;
   320           }
   321&n= bsp;      &nbs= p; 
= -> 322      = ;   &nbs= p;Buffer =3D CoreAllocatePoolPages (PoolType, NoPages, Granularity, NeedGua= rd);
   323    CoreRele= aseMemoryLock ();
   324         
   325           if (B= uffer !=3D NULL) {
(lldb) p Status
(unsign= ed long long) $3 =3D 0
 
Structures w= ork more or less fine, but for simpler types like strings we are out of eve= n potential pretty-printing.
 
 
Vitaly,
<= /div>
&nbs= p;
You can teach lldb about types. There is some example code here: https= ://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py

2. Global variables are not accessible. I a= m not sure what happens, but they either seem to not relocate or conflict w= ith the other names:
 
(lldb) p gST=
error: Couldn't materialize: couldn't get the value of varia= ble ::gST: read memory from 0x6e18 failed
error: errored out = in DoExecute, couldn't PrepareToExecuteJITExpression
(lldb)&n= bsp;p &gST
error: Couldn't materialize: couldn't get the = value of variable ::gST: read memory from 0x6e18 failed
error= : errored out in DoExecute, couldn't PrepareToExecuteJITExpression
 
 
Th= at is strange as globals usually work best? The common issue I've seen is g= etting the slide wrong. The EFI modules are linked at a value near zero and= relocated into memory, so the slide represents that adjustment. 
 
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: SimSun= ;" class=3D"">You can use `image dump sections` and `&nb= sp;image dump symtab` to see lldb's view of symbols. More info here [1].&nb= sp;


3. Quite a number of crashes.
 
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: SimSun= ;" class=3D"">In most cases autocompletion by tab press = causes a crash. E.g.
 
b I<TAB>
 
So will do printing of a GUID, e.g. = ;p gEfiGlobalVariableGuid.
 
This may have to do wi= th Python compatibility as Xcode 11 LLDB that uses Python 3 generally crash= es more often than MacPorts LLDB 9.0. Surprisingly structures work more or less fine.=
 
 
=
You can tell lldb to use = the older Python like this (from the Terminal.app):
$ = ;defaults write com.apple.dt.lldb DefaultPythonVersion 2


4. Ctrl+C does not produce a valid backtrace. When I b= reak with a breakpoint, I see a proper stacktrace with more than one entry,= with function prototypes and values. When I break with Ctrl+C I only see s= ome weird backtrace with most of the entries missing regardless of frame po= sition:
<= div class=3D"">
 
(lldb) bt
* thread #1, stop reason =3D signal SIGT= RAP
  * frame #0: 0x000000007fe4c5f3 DxeC= ore.dll
<= div class=3D"">
 
Probably more and all the unintuitive stuff like the lack of more function= al TUI, but it is hard to remember all the trials.
 
&= nbsp;
For the macOS API clang emits frame pointers, so you can walk the st= ack without symbols. You could try adding the compiler flag to emit the fra= me pointers. 
=
 
=
&nb= sp;
[1] https://github.com/acida= nthera/OpenCorePkg/blob/master/Debug/Scripts/lldb_uefi.py
 
 
On macOS t= he Mach-O and dSYM have a UUID (dwarfdump -u) that is indexed by Spotlight = (mdfind "com_apple_xcode_dsym_uuids =3D=3D *") [2]
This s= hould be the UUID in the debug directory entry and you can use that to look= up the symbols like this:
 
module =3D t= arget.AddModule (None, None, uuid)
=
SBError =3D target.SetMod= uleLoadAddress (module, LoadAddress + TeAdjust)
 
Also lldb has built in help for commands, but it is kind of te= rse since it is autogenerated from the C++ swig. 
(lldb)=  script help (lldb.target.AddModule)
Help on method AddModule in module lldb:
 <= /o:p>
AddModul= e(self, *args) method of lldb.SBTarget instance
    AddMo= dule(SBTarget self, SBModule module) -> bool
    AddMo= dule(SBTarget self, char const * path, char const * triple, char const * uu= id) -> SBModule
=
    AddModule(SBTarget self, char cons= t * path, char const * triple, char const * uuid_cstr, char const * symfile= ) -> SBModule
    AddModule(SBTarget self, SBModuleSpe= c module_spec) -> SBModule


=
The minimum  you need to symbolicate a frame is uuid, = LoadAddress, and PC. 
 
[1] http://lldb.llvm.org/use/map.html
[2] http://lldb.llvm.org/use/symbols.html
 
Thanks,<= /o:p>
<= o:p class=3D""> 
Andrew Fish
 


<= o:p class=3D"">
Best wishes,
Vitaly
 
20 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., = =D0=B2 22:14, Andrew Fish <afish@apple.com>= ; =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):=
 =



On Mar 20, 2020, at 8:13 AM, Vitaly Cheptsov &= lt;cheptsov@ispras.ru> wrote:
 
<= span lang=3D"EN-US" style=3D"font-size: 9pt; font-family: Helvetica, sans-s= erif;" class=3D"">Hello,
=
 
=
We noticed that the= original bugzilla, which intended to add new LLVM toolchain support[1], al= so wanted to bring ELF format support with DWARF debugging information.&nbs= p;For some reason this did not make its way into EDK II, and we are current= ly wondering, how can one debug binaries built with LLVM 9.0.


For macOS and XCODE5 toolch= ain we use GDB scripts based on Andrei Warkentin=E2=80=99s work, which= allow us to integrate with QEMU and VMware[2]. It is likely that they shou= ld work with little to no work on Linux with CLANG38/GCC5 with GDB once aga= in. However, CLANGPDB apparently is using PDB debugging information, which = I believe is not handled with GDB.
=
 
Cou= ld you please provide the details on the matter and let us know about the r= ecommended route?
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: SimSun= ;" class=3D"">=E2=80=94 Is dropping CLANGELF just a temp= orary measure and it should be resubmitted again?
=E2=80=94&= nbsp;Should LLDB, which seems to be aware of PDB, be used instead of GDB, w= hen building with CLANGPDB? If so, did anybody try that?

<= /div>
 
Vitaly,
 
I've not tri= ed the CLANGPDB path, but if you want to connect lldb to QEMU you need to s= et  plugin.process.gdb-remote.target-definition-file [1] to [2]. =
 
[1]  lldb -o "settings s= et plugin.process.gdb-remote.target-definition-file x86_64_target_definitio= n.py" -o "gdb-remote 9000"
 
Thanks,
 
Andrew Fis= h

=
Thanks!=
=

Best regards,=
= Vitaly
 
[1] https://bugzilla.tianocore.org/show_bug.= cgi?id=3D1603
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: SimSun= ;" class=3D"">[2] https://github.com/acidanthe= ra/OpenCorePkg/blob/master/Debug/Scripts/gdb_uefi.py
 
=
 =
 
=
<crashes.txt>=
 
=
--Apple-Mail=_20A622B7-7708-4A3C-BA59-ACC83EE9DCEB-- --Apple-Mail=_D2FB297D-3399-4E97-814F-6314E8A8B2CD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEsLABAI5Y5VbvBdmpL8K2O86Eyz4FAl57WoYACgkQL8K2O86E yz4pSg/+Lxism345wSz8n+Ji6be85PjPYpWbDpdTFpTgp5mr8Ba6kuKiwqFeNpkI ntpRD5NYVp8vS85r55OFfiRdHU6PWOHeY0NZMMRg0quCxArqsv9s77GHZo9V2dV7 Ob2piNszDdJHdfrE4LivC/9WvwCpwuQYiHVm3hDjKhr52/ZjMWArL8IPqoYx7yyV G0WJMmpKtwdYsDbrNs163gCaXbJPQ8aXXLuWBKT4ownNGrgmbCNjOpdO9HHznzdk a7fXX+dJHCuv+nZiMkoK8JzCwju32BvshhriZ+dFYc3VUa0yEfWRjGbXKfSzSRME +pFkXWTZLHXDJ9WFJm9+KSO30hFteV2jry6n5aCXgKN3GMibCZ+s/QptEeelWFSf ugbPDaG3NfOg2TFSvsxz/4ZpLAnrvInEhSlu60NrKd64Qa0rA5zpSmnnWQtji33m k1jMoKGn7US6+MTooQ5Qa2i/fZnMN60JSj3zWiu3NyFRAcalZHNJp55XhzjbEg07 OA2fXmjZGhmKEfbQONJlhMeabhoeAgnd2LHclmqohKHMKyw3hUMVWplIQykPp5S3 DcsI9KpECB/bfu7UV+ooQUCyeOCvL7ps3AuHaJbuIiap0Z/mjWOb5U3pmIa5lA/E ssle1ClIrE6LJtTXuXzuOYptnwwQ6deLOzaB6vgJKP13yxC60mw= =4J1E -----END PGP SIGNATURE----- --Apple-Mail=_D2FB297D-3399-4E97-814F-6314E8A8B2CD--