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.web10.48777.1584954619651030177 for ; Mon, 23 Mar 2020 02:10:20 -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 [77.232.9.83]) by mail.ispras.ru (Postfix) with ESMTPSA id D30C6653; Mon, 23 Mar 2020 12:10:15 +0300 (MSK) From: "Vitaly Cheptsov" Message-Id: <3D39F81F-6EBC-4079-8FC0-0112D756F0EB@ispras.ru> Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: [edk2-devel] CLANGPDB binary debugging Date: Mon, 23 Mar 2020 12:10:14 +0300 In-Reply-To: Cc: devel@edk2.groups.io, =?utf-8?Q?Marvin_H=C3=A4user?= To: Andrew Fish , "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> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Groupsio-MsgNum: 56100 Content-Type: multipart/signed; boundary="Apple-Mail=_750CC4C3-238E-4A77-B88F-D079B932DB45"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_750CC4C3-238E-4A77-B88F-D079B932DB45 Content-Type: multipart/alternative; boundary="Apple-Mail=_3A9DFBBC-1A3D-40F3-A555-21D0D51CC107" --Apple-Mail=_3A9DFBBC-1A3D-40F3-A555-21D0D51CC107 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Andrew, I investigated further and was able to make some progress. I got rid of PD= B, and changed debug information generation to DWARF[1]. This resolved most= of LLDB crashes and made pretty-printing work just fine as type aliases li= ke EFI_STATUS now work correctly (I am still to commit this). Unfortunately= there are several downsides. Dead code stripping in LLD linker is broken w= hen generating PE with DWARF, so I had to patch it[2]. Debug link implement= ation in llvm-objcopy is also quite ugly, we do not get MTOC or anything al= ike[3], just some section with a random name containing base filename. I can submit a more proper patch to EDK II properly implementing CLANGDWAR= F toolchain instead of patching CLANGPDB like in [1], but it is questionabl= e whether it is worth it. LLVM 10 will land very soon, and the necessary LL= D patches[2] will definitely not make their way in this release. We will ha= ve to wait for LLVM 11 at the very least, and I am not sure I am ready to d= rive llvm-objcopy changes either. Liming, what do you think? > 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) 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 mist= ake. Now I have a fake target for GdbSyms and a proper target for other ima= ges[4]. This somewhat solves the issue with invalid addresses for gST, as g= ST from DxeCore is now picked. However, I cannot access global variables fr= om other modules for some reason still. > 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: > =09Module =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 Something is really weird, gST from the first image shows, but lldb believ= es that it does not exist. lldb.target.FindGlobalVariables ("gST", 1024) al= so returns an empty list. I noticed that LLDB shows invalid type for gST in the symtab, there also i= s no address. I started to wonder whether this is the cause and decided to = check XCODE5, as the the issue could have been with PE format. Unfortunatel= y even after I tried XCODE5 support with LLDB, I got exactly the same probl= em. I am quite clueless what is going on. Below I included two transcripts:= for CLANGDWARF and XCODE5. (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, Head= erSize =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_CLAN= GPDB/X64/DxeCore.debug' (x86_64): SectID Type Load Address Per= m File Off. File Size Flags Section Name ---------- ---------------- --------------------------------------- ---= - ---------- ---------- ---------- ---------------------------- 0xffffffffffffffff container [0x000000007fe1b000-0x000000007ff38a= c0) --- 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_CLAN= GPDB/X64/DevicePathDxe.debug' (x86_64): SectID Type Load Address Per= m File Off. File Size Flags Section Name ---------- ---------------- --------------------------------------- ---= - ---------- ---------- ---------- ---------------------------- 0xffffffffffffffff container [0x000000007f986000-0x000000007f9cb0= a0) --- 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_C= LANGPDB/X64/DxeCore.debug, num_symbols =3D 4343: Debug symbol |Synthetic symbol ||Externally Visible ||| Index UserID DSX Type File Address/Value Load Address S= ize Flags Name ------- ------ --- --------------- ------------------ ------------------ -= ----------------- ---------- ---------------------------------- [ 0] 4294967295 Invalid 0x0000000000000000 0x000000007fe1b0= 00 0x000000000000003a 0x00000000 .text [ 1] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .data [ 2] 4294967295 Invalid 0x0000000000001898 = 0x0000000000000000 0x00000000 .bss [ 3] 4294967295 Invalid 0x0000000000046bc0 0x000000007fe61b= c0 0x0000000000000374 0x00000000 .text$_ModuleEntryPoint [ 4] 4294967295 Code 0x0000000000046bc0 0x000000007fe61b= c0 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 0x000000007fe5a6= 80 0x0000000000000020 0x00000000 ProcessModuleEntryPointList [ 18] 4294967295 Code 0x0000000000023130 0x000000007fe3e1= 30 0x0000000000000020 0x00000000 DebugAssertEnabled [ 19] 4294967295 Code 0x0000000000023060 0x000000007fe3e0= 60 0x00000000000000d0 0x00000000 DebugAssert [ 20] 4294967295 Code 0x0000000000022150 0x000000007fe3d1= 50 0x0000000000000020 0x00000000 CpuDeadLoop [ 21] 4294967295 Invalid 0x0000000000000000 0x000000007fe1b0= 00 0x000000000000003a 0x00000000 .text [ 22] 4294967295 Invalid 0x0000000000000000 = 0x0000000000000000 0x00000000 .data [ 23] 4294967295 Invalid 0x0000000000001898 = 0x0000000000000000 0x00000000 .bss [ 24] 4294967295 Invalid 0x000000000003f240 0x000000007fe5a2= 40 0x0000000000000440 0x00000000 .text$ProcessLibraryConstructorList [ 25] 4294967295 Code 0x000000000003f240 0x000000007fe5a2= 40 0x0000000000000440 0x00000000 ProcessLibraryConstructorList [ 26] 4294967295 Invalid 0x000000000003f680 0x000000007fe5a6= 80 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 =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 { Hdr =3D (Signature =3D 0x5453595320494249, Revision =3D 0x00020046, Head= erSize =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_XCOD= E5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll' (x86_64): SectID Type Load Address Per= m 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) rw-= 0x00045da0 0x00001ae0 0x00000000 DxeCore.dll.__DATA 0x00000005 regular [0x000000007fe6bb40-0x000000007fe6bd58) rw-= 0x00045da0 0x00000218 0x00000000 DxeCore.dll.__DATA.__const 0x00000006 data [0x000000007fe6bd60-0x000000007fe6d610) rw-= 0x00045fc0 0x000018b0 0x00000000 DxeCore.dll.__DATA.__data 0x00000007 zero-fill [0x000000007fe6d610-0x000000007fe70e20) rw-= 0x00000000 0x00000000 0x00000001 DxeCore.dll.__DATA.__common 0x00000008 zero-fill [0x000000007fe70e20-0x000000007fe70e58) rw-= 0x00000000 0x00000000 0x00000001 DxeCore.dll.__DATA.__bss 0x00000100 container [0x000000000004b000-0x00000000000ef000)* rw-= 0x00001000 0x000a3a74 0x00000000 DxeCore.dll.__DWARF 0x00000001 dwarf-line [0x000000000004b000-0x00000000000723fb)* rw-= 0x00001000 0x000273fb 0x00000000 DxeCore.dll.__DWARF.__debug_line 0x00000002 dwarf-pubnames [0x00000000000723fb-0x0000000000078429)* rw-= 0x000283fb 0x0000602e 0x00000000 DxeCore.dll.__DWARF.__debug_pubnames 0x00000003 dwarf-pubtypes [0x0000000000078429-0x000000000008b915)* rw-= 0x0002e429 0x000134ec 0x00000000 DxeCore.dll.__DWARF.__debug_pubtypes 0x00000004 dwarf-aranges [0x000000000008b915-0x000000000008ea65)* rw-= 0x00041915 0x00003150 0x00000000 DxeCore.dll.__DWARF.__debug_aranges 0x00000005 dwarf-info [0x000000000008ea65-0x00000000000c78bf)* rw-= 0x00044a65 0x00038e5a 0x00000000 DxeCore.dll.__DWARF.__debug_info 0x00000006 dwarf-frame [0x00000000000c78bf-0x00000000000cc697)* rw-= 0x0007d8bf 0x00004dd8 0x00000000 DxeCore.dll.__DWARF.__debug_frame 0x00000007 dwarf-ranges [0x00000000000cc697-0x00000000000cc757)* rw-= 0x00082697 0x000000c0 0x00000000 DxeCore.dll.__DWARF.__debug_ranges 0x00000008 dwarf-abbrev [0x00000000000cc757-0x00000000000cca9b)* rw-= 0x00082757 0x00000344 0x00000000 DxeCore.dll.__DWARF.__debug_abbrev 0x00000009 dwarf-str [0x00000000000cca9b-0x00000000000dcc05)* rw-= 0x00082a9b 0x0001016a 0x00000000 DxeCore.dll.__DWARF.__debug_str 0x0000000a apple-names [0x00000000000dcc05-0x00000000000e2439)* rw-= 0x00092c05 0x00005834 0x00000000 DxeCore.dll.__DWARF.__apple_names 0x0000000b apple-namespaces [0x00000000000e2439-0x00000000000e245d)* rw-= 0x00098439 0x00000024 0x00000000 DxeCore.dll.__DWARF.__apple_namespac 0x0000000c apple-types [0x00000000000e245d-0x00000000000eea50)* rw-= 0x0009845d 0x0000c5f3 0x00000000 DxeCore.dll.__DWARF.__apple_types 0x0000000d apple-objc [0x00000000000eea50-0x00000000000eea74)* rw-= 0x000a4a50 0x00000024 0x00000000 DxeCore.dll.__DWARF.__apple_objc Sections for '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_XCOD= E5/X64/MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe/DEBUG/DevicePathD= xe.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_X= CODE5/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 S= ize Flags Name ------- ------ --- --------------- ------------------ ------------------ -= ----------------- ---------- ---------------------------------- [ 0] 118 D SourceFile 0x0000000000000000 S= ibling -> [ 20] 0x00640000 /Users/user/Documents/UefiPackages/MdeModulePk= g/Core/Dxe/SectionExtraction/CoreSectionExtraction.c [ 1] 120 D ObjectFile 0x000000005e78588d 0= x0000000000000000 0x00660001 /Users/user/Documents/UefiWorkspace/Build/Ovmf= X64/NOOPT_XCODE5/X64/MdeModulePkg/Core/Dxe/DxeMain/OUTPUT/DxeCore.lib(CoreS= ectionExtraction.obj) [ 2] 122 D X Code 0x0000000000000240 0x000000007fe26240 0= x0000000000000260 0x000f0000 CustomGuidedSectionExtract [ 3] 126 D X Code 0x00000000000004a0 0x000000007fe264a0 0= x0000000000000110 0x000f0000 InitializeSectionExtraction [ 4] 130 D X Code 0x00000000000005b0 0x000000007fe265b0 0= x0000000000000140 0x000f0000 IsValidSectionStream [ 5] 134 D X Code 0x00000000000006f0 0x000000007fe266f0 0= x0000000000000180 0x000f0000 OpenSectionStreamEx [ 6] 138 D X Code 0x0000000000000870 0x000000007fe26870 0= x0000000000000070 0x000f0000 OpenSectionStream [ 7] 142 D X Code 0x00000000000008e0 0x000000007fe268e0 0= x0000000000000100 0x000f0000 ChildIsType =E2=80=A6 [ 831] 2470 D X Code 0x00000000000306b0 0x000000007fe566b0 0= x00000000000000f4 0x000f0000 UefiBootServicesTableLibConstructor [ 832] 2473 D X Data 0x0000000000047780 0x000000007fe6d780 0= x0000000000000008 0x000f0000 gImageHandle [ 833] 2474 D X Data 0x0000000000047788 0x000000007fe6d788 0= x0000000000000008 0x000f0000 gST [ 834] 2475 D X Data 0x0000000000047790 0x000000007fe6d790 0= x0000000000000008 0x000f0000 gBS =E2=80=A6 > This is easy enough to check as %rpb is the frame pointer so it will get= saved/restored on function entry/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: 0x000000007fe49f3c DxeCore.dll`CoreRestoreTpl(NewTpl=3D0x000= 0000000000008) at Tpl.c:102:12 frame #1: 0x000000007e518c95 thread #2 frame #0: 0x000000007fb3ff88 CpuDxe.dll`CpuSleep + 1 frame #1: 0x000000007fb4d719 CpuDxe.dll`ApWakeupFunction(ExchangeInfo= =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(ExchangeInfo= =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(ExchangeInfo= =3D0x0000000000087198, ApIndex=3D0x0000000000000003) at MpLib.c:768:9 frame #2: 0x000000007fb2d151 Best wishes, Vitaly [1] https://github.com/acidanthera/OpenCorePkg/blob/7684a9f/Debug/ClangDwa= rf.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/3e5f3f3f9a8d3f197834= bbfcf5029f771df89754 > 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 >> 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 ans= wered inline explaining the particular issues, which mostly seem to be spec= ific to CLANGPDB. LLVM stack emits PDB debug files, and even though LLDB do= es support them to some level, it is unlikely that this will be working wel= l enough soon. We should really stick to more or less native debug formats,= ideally those that have proper open specifications, on all platforms, and = for 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 >> I am pretty sure LLVM can be taught to emit DWARF debug information eve= n for PE files. Perhaps we can either make some option or provide a separat= e toolchain for this? Another way would be recovering CLANGELF as originall= y 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 >>> You can teach lldb about types. There is some example code here: https= ://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py >> This code works just fine with LLDB and DWARF (e.g. XCODE5), though I h= ave not yet completed these changes for my scripts for LLDB, only for GDB. = However, 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 k= now 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 in= formation 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 sour= ce level debugging works just fine and symbolication works fine, so it shou= ld be some bug with PDB in particular. >>=20 >>> That is strange as globals usually work best? The common issue I've se= en is getting the slide wrong. The EFI modules are linked at a value near z= ero 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. = It 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/NOOP= T_CLANGPDB/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll, num_symbols= =3D 0 >> Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOP= T_CLANGPDB/X64/MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe/DEBUG/Dev= icePathDxe.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 = first 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 lin= e. With GDB the closest symbol is used, but with LLDB it is always coming f= rom 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 >> 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 basica= lly I cannot slide what is not in the memory, and this is also my first ima= ge. 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 >> (lldb) image dump sections >> Dumping sections for 91 modules. >> Sections for 'GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll' (x86_64): >> SectID Type Load Address = Perm File Off. File Size Flags Section Name >> ---------- ---------------- --------------------------------------- = ---- ---------- ---------- ---------- ---------------------------- >> 0xffffffffffffffff container [0x0000000000000000-0x00000000000= 06ec0)* --- 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_C= LANGPDB/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll' (x86_64): >> SectID Type Load Address = Perm File Off. File Size Flags Section Name >> ---------- ---------------- --------------------------------------- = ---- ---------- ---------- ---------- ---------------------------- >> 0xffffffffffffffff container [0x0000000000000000-0x00000000000= 523a0)* --- 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_C= LANGPDB/X64/MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe/DEBUG/Device= PathDxe.dll' (x86_64): >> SectID Type Load Address = Perm File Off. File Size Flags Section Name >> ---------- ---------------- --------------------------------------- = ---- ---------- ---------- ---------- ---------------------------- >> 0xffffffffffffffff container [0x0000000000000000-0x00000000000= 14420)* --- 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 ac= cess duplicating variables. They either resolve to GdbSyms or just cause a = crash: >>=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: = read memory from 0x6df8 failed >> error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression >> (lldb) p gEfiGlobalVariableGuid >> 0 libLLVM.dylib 0x000000010e52ee68 llvm::sys::PrintStackTra= ce(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: > =09Module =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 >>> You can tell lldb to use the older Python like this (from the Terminal= .app): >>> $ defaults write com.apple.dt.lldb DefaultPythonVersion 2 >>=20 >> Thanks, that helped quite a bit, but for some reason Xcode version stil= l 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 stac= k without symbols. You could try adding the compiler flag to emit the frame= pointers. >>=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 >> I am pretty sure stack frames are not disabled with UEFI, as sometimes = backtracing works just fine. To me it looks like debug information parsing = randomly 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 Loca= te.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(Sea= rchType=3DByProtocol, Protocol=3D0x000000007f978160, SearchKey=3D0x00000000= 00000000, NumberHandles=3D0x000000007fe19fd8, Buffer=3D0x000000007fe19fc0) = at Locate.c:649 >> 646 =09 EFI_STATUS Status; >> 647 =09 UINTN BufferSize; >> 648 >> -> 649 =09 if (NumberHandles =3D=3D NULL) { >> 650 =09 return EFI_INVALID_PARAMETER; >> 651 =09 } >> 652 >> (lldb) bt >> * thread #1, stop reason =3D breakpoint 2.1 >> * frame #0: 0x000000007fe36e4f DxeCore.dll`CoreLocateHandleBuffer(Sea= rchType=3DByProtocol, Protocol=3D0x000000007f978160, SearchKey=3D0x00000000= 00000000, NumberHandles=3D0x000000007fe19fd8, Buffer=3D0x000000007fe19fc0) = at Locate.c:649 >> frame #1: 0x000000007fe36816 DxeCore.dll`CoreLocateDevicePath(Proto= col=3D0x000000007f978160, DevicePath=3D0x000000007fe1a060, Device=3D0x00000= 0007fe1a068) 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= =3D0x000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at= CopyMemWrapper.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)DestinationBu= ffer)); >> (lldb) bt >> * thread #1, stop reason =3D breakpoint 2.53 3.53 >> * frame #0: 0x000000007e5c13b3 MnpDxe.dll`CopyMem(DestinationBuffer= =3D0x000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at= CopyMemWrapper.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= =3D0x000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at= CopyMemWrapper.c:50 >> 47 if (Length =3D=3D 0) { >> 48 return DestinationBuffer; >> 49 } >> -> 50 ASSERT ((Length - 1) <=3D (MAX_ADDRESS - (UINTN)DestinationBu= ffer)); >> 51 ASSERT ((Length - 1) <=3D (MAX_ADDRESS - (UINTN)SourceBuffer)= ); >> 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= =3D0x000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at= CopyMemWrapper.c:57 >> 54 return DestinationBuffer; >> 55 } >> 56 return InternalMemCopyMem (DestinationBuffer, SourceBuffer, L= ength); >> -> 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 indexe= d 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 t= hat to lookup the symbols like this: >>>=20 >>> module =3D target.AddModule (None, None, uuid) >>> SBError =3D target.SetModuleLoadAddress (module, LoadAddress + TeAdjus= t) >>>=20 >>> Also lldb has built in help for commands, but it is kind of terse sinc= e 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, c= har const * uuid) -> SBModule >>> AddModule(SBTarget self, char const * path, char const * triple, c= har const * uuid_cstr, char const * symfile) -> SBModule >>> AddModule(SBTarget self, SBModuleSpec module_spec) -> SBModule >>>=20 >>> The minimum you need to symbolicate a frame is uuid, LoadAddress, and= PC. >>>=20 >>> [1] http://lldb.llvm.org/use/map.html >>> [2] http://lldb.llvm.org/use/symbols.html >> Thanks for the links again. Yes, I am using some of these, and in fact = for 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 i= t even better will only help myself, but not other people with e.g. Linux o= r 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 >> Best regards, >> Vitaly >>=20 >>=20 >>> 21 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0=B2 20:13, Andrew F= ish > =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0=D0=BB(=D0=B0): >>>=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 s= cripts 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. >>>>=20 >>>> Unfortunately the experience was close to terrible. I may certainly d= o something wrong, but it is clear that PDB and LLDB do not support each ot= her well enough. After spending several hours on playing with the tools 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 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 t= ypes. This way EFI_STATUS and EFI_TPL become unsigned long long, CHAR8 beco= mes char, and CHAR16 becomes unsigned short. It does not look like LLDB has= the original types anywhere at all, and it also does not have them registe= red. >>>>=20 >>>> frame #0: 0x000000007fe242aa DxeCore.dll`CoreAllocatePoolPagesI(P= oolType=3DEfiBootServicesData, NoPages=3D1, Granularity=3D4096, NeedGuard= =3D'\0') at Pool.c:322 >>>> 319 =09 return NULL; >>>> 320 =09 } >>>> 321 >>>> -> 322 =09 Buffer =3D CoreAllocatePoolPages (PoolType, NoPages, Gran= ularity, NeedGuard); >>>> 323 =09 CoreReleaseMemoryLock (); >>>> 324 >>>> 325 =09 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 >>>> 2. Global variables are not accessible. I am not sure what happens, b= ut 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= : read memory from 0x6e18 failed >>>> error: errored out in DoExecute, couldn't PrepareToExecuteJITExpressi= on >>>> (lldb) 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 PrepareToExecuteJITExpressi= on >>>>=20 >>>=20 >>> That is strange as globals usually work best? The common issue I've se= en is getting the slide wrong. The EFI modules are linked at a value near z= ero 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 >>>> 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 u= ses Python 3 generally crashes more often than MacPorts LLDB 9.0. Surprisin= gly structures work more or less fine. >>>>=20 >>>=20 >>> You can tell lldb to use the older Python like this (from the Terminal= .app): >>> $ defaults write com.apple.dt.lldb DefaultPythonVersion 2 >>>=20 >>>> 4. Ctrl+C does not produce a valid backtrace. When I break with a bre= akpoint, I see a proper stacktrace with more than one entry, with function = prototypes and values. When I break with Ctrl+C I only see some weird backt= race 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 fun= ctional 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 stac= k without symbols. You could try adding the compiler flag to emit the frame= pointers. >>>=20 >>>=20 >>>> [1] https://github.com/acidanthera/OpenCorePkg/blob/master/Debug/Scri= pts/lldb_uefi.py >>>>=20 >>>=20 >>> On macOS the Mach-O and dSYM have a UUID (dwarfdump -u) that is indexe= d 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 t= hat to lookup the symbols like this: >>>=20 >>> module =3D target.AddModule (None, None, uuid) >>> SBError =3D target.SetModuleLoadAddress (module, LoadAddress + TeAdjus= t) >>>=20 >>> Also lldb has built in help for commands, but it is kind of terse sinc= e 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, c= har const * uuid) -> SBModule >>> AddModule(SBTarget self, char const * path, char const * triple, c= har const * uuid_cstr, char const * symfile) -> SBModule >>> AddModule(SBTarget self, SBModuleSpec module_spec) -> SBModule >>>=20 >>> The minimum you need to symbolicate a frame is uuid, LoadAddress, and= PC. >>>=20 >>> [1] http://lldb.llvm.org/use/map.html >>> [2] http://lldb.llvm.org/use/symbols.html >>>=20 >>> Thanks, >>>=20 >>> Andrew Fish >>>=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= Fish > =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB(=D0=B0): >>>>>=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 LL= VM toolchain support[1], also wanted to bring ELF format support with DWARF= debugging information. For some reason this did not make its way into EDK = II, and we are currently wondering, how can one debug binaries built with L= LVM 9.0. >>>>>>=20 >>>>>> For macOS and XCODE5 toolchain we use GDB scripts based on Andrei W= arkentin=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 = CLANG38/GCC5 with GDB once again. However, CLANGPDB apparently is using PDB= debugging 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 shou= ld be resubmitted again? >>>>>> =E2=80=94 Should LLDB, which seems to be aware of PDB, be used inst= ead of GDB, when building with CLANGPDB? If so, did anybody try that? >>>>>>=20 >>>>>=20 >>>>> Vitaly, >>>>>=20 >>>>> I've not tried the CLANGPDB path, but if you want to connect lldb to= QEMU 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-definiti= on-file 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 >>>>>> Thanks! >>>>>>=20 >>>>>> Best regards, >>>>>> Vitaly >>>>>>=20 >>>>>> [1] https://bugzilla.tianocore.org/show_bug.cgi?id=3D1603 >>>>>> [2] https://github.com/acidanthera/OpenCorePkg/blob/master/Debug/Sc= ripts/gdb_uefi.py >>>>>>=20 >>>>=20 >>=20 >>=20 >> --Apple-Mail=_3A9DFBBC-1A3D-40F3-A555-21D0D51CC107 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Andrew,
I investigated further and was able to m= ake some progress. I got rid of PDB, and changed debug information generati= on to DWARF[1]. This resolved most of LLDB crashes and made pretty-printing= work just fine as type aliases like EFI_STATUS now work correctly (I am st= ill to commit this). Unfortunately there are several downsides. Dead code s= tripping 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 quite ugly,= we do not get MTOC or anything alike[3], just some section with a random n= ame containing base filename.

I can submit a more proper patch to EDK II properly implementi= ng CLANGDWARF toolchain instead of patching CLANGPDB like in [1], but it is= questionable 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 a= m ready to drive llvm-objcopy changes either. Liming, what do you think?

I've not used the fake image to get thing= s done so I can't speak to that. I have used a fake target so I could have = XIP PEIM and shadowed PEIM address available at the same time. You can't ha= ve a module loaded at 2 addresses at the same time in llldb. But you might = be able to use a fake target for your fake stuff?

Just in case:

        &= nbsp; # create a faka target to store info about symbols
          PeiXipTarget =3D target.debugger.Crea= teTarget (None, "i386-apple-macosx", "remote-macosx", True, error)

      &nbs= p;   # make sure the gdb-remote  connection target is the active = target
          target.debug= ger.SetSelectedTarget (target)

Yes, that was actually a smart idea. I initially did it th= at 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 proper targ= et for other images[4]. This somewhat solves the issue with invalid address= es for gST, as gST from DxeCore is now picked. However, I cannot access glo= bal variables from other modules for some reason still.

If you want to inspect globals I think this logic works to= get you data, you would need to print it out etc. 

SBValueList =3D lldb.target.FindGlo= balVariables ("gST", 1024)
for SBValue in SBValueList:=
Module =3D SBValue.GetAddress().GetModule() 
        ModuleStr =3D SBValue.GetAddress().Ge= tModule().GetFileSpec().GetFilename()
    &n= bsp;   Start =3D int (SBValue.GetLocation(), 0)
&= nbsp;       End =3D Start + SBValue.GetByteSize() - 1
<= div class=3D"">        SBDeclaration =3D SBValue.= GetDeclaration()
        Column = =3D S= BDeclaration.GetColumn()

<= div class=3D"">I wrote a command in the early days to dump out all the inst= ances of a global. 

You can also try (lldb) image lookup -Av --name gST

Something is = really weird, gST from the first image shows, but lldb believes that it doe= s not exist. lldb.target.FindGlobalVariables ("gST", 1024) also return= s an empty 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 going on. Below I in= cluded two transcripts: for CLANGDWARF and XCODE5.

(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, H= eaderSize =3D 0x00000078, CRC32 =3D 0x3d5e9b5d, Reserved =3D 0x00000000)  FirmwareVendor =3D 0x000000007f9e9c98
  FirmwareRevision =3D 0x00010000
  Cons= oleInHandle =3D 0x000000007ed58f18
  ConIn =3D 0x00= 0000007e6edcb8
  ConsoleOutHandle =3D 0x000000007ed= 57018
  ConOut =3D 0x000000007e6ede40
  StandardErrorHandle =3D 0x000000007ed57a98
 = ; StdErr =3D 0x000000007e6ee030
  RuntimeServi= ces =3D 0x000000007f9eeb98
  BootServices =3D 0x000= 000007fe689e8
  NumberOfTableEntries =3D 0x00000000= 0000000a
  ConfigurationTable =3D 0x000000007f9eec9= 8
}
(lldb) image lookup -Av --name gST
(lldb) image dump sections
Dumping sections f= or 90 modules.
Sections for '/Users/user/Documents/UefiWorksp= ace/Build/OvmfX64/NOOPT_CLANGPDB/X64/DxeCore.debug' (x86_64):
  SectID     Type       =       Load Address         &nb= sp;                   Per= m File Off.  File Size  Flags      = Section Name
  ---------- ---------------- --------= -------------------------------  ---- ---------- ---------- -----= ----- ----------------------------
  0xffffffffffff= ffff container        [0x000000007fe1b000-0x000000= 007ff38ac0)  ---  0x00000000 0x00000000 0x00000000 DxeC= ore.debug.
  0x00000001 code     &nb= sp;       [0x000000007fe1b320-0x000000007fe61f34) =  ---  0x00000320 0x00046c20 0x60000020 DxeCore.debug...text<= br class=3D"">  0x00000002 data         =     [0x000000007fe61f40-0x000000007fe680f1)  ---&n= bsp; 0x00046f40 0x000061c0 0x40000040 DxeCore.debug...rdata
  0x00000003 data           =   [0x000000007fe68100-0x000000007fe6d1e0)  --- &nb= sp;0x0004d100 0x000018a0 0xc0000040 DxeCore.debug...data
&nbs= p; 0x00000004 regular          [0x000000= 007fe6d1e0-0x000000007fe6d424)  ---  0x0004e9a0 0x00000= 260 0x42000040 DxeCore.debug...reloc
  0x00000005 d= warf-abbrev     [0x000000007fe6d440-0x000000007fe74059)=   ---  0x0004ec00 0x00006c20 0x42000040 DxeCore.debug..= .debug_abbrev
  0x00000006 dwarf-info   &= nbsp;   [0x000000007fe74060-0x000000007fec1355)  ---&nb= sp; 0x00055820 0x0004d300 0x42000040 DxeCore.debug...debug_info
  0x00000007 dwarf-line       [0= x000000007fec1360-0x000000007fef9fd4)  ---  0x000a2b20 = 0x00038c80 0x42000040 DxeCore.debug...debug_line
  = 0x00000008 dwarf-macinfo    [0x000000007fef9fe0-0x000000007f= efa056)  ---  0x000db7a0 0x00000080 0x42000040 DxeCore.= debug...debug_macinfo
  0x00000009 dwarf-ranges&nbs= p;    [0x000000007fefa060-0x000000007feff610)  ---=   0x000db820 0x000055c0 0x42000040 DxeCore.debug...debug_ranges  0x0000000a dwarf-str       &nb= sp;[0x000000007feff620-0x000000007ff38abd)  ---  0x000e= 0de0 0x000394a0 0x42000040 DxeCore.debug...debug_str
Sections= for '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_CLANGPDB/X64/= DevicePathDxe.debug' (x86_64):
  SectID  =   Type             Load = Address                  =           Perm File Off.  File Siz= e  Flags      Section Name
&nbs= p; ---------- ---------------- ---------------------------------------=   ---- ---------- ---------- ---------- -------------------------= ---
  0xffffffffffffffff container    &nb= sp;   [0x000000007f986000-0x000000007f9cb0a0)  --- = ; 0x00000000 0x00000000 0x00000000 DevicePathDxe.debug.
=   0x00000001 code            &= nbsp;[0x000000007f986320-0x000000007f996dc6)  ---  0x00= 000320 0x00010ac0 0x60000020 DevicePathDxe.debug...text
 = ; 0x00000002 data             = [0x000000007f996de0-0x000000007f999b75)  ---  0x00010de= 0 0x00002da0 0x40000040 DevicePathDxe.debug...rdata
 &nb= sp;0x00000003 data             [0x0= 00000007f999b80-0x000000007f99a202)  ---  0x00013b80 0x= 00000660 0xc0000040 DevicePathDxe.debug...data
  0x= 00000004 regular          [0x000000007f99a220= -0x000000007f99a464)  ---  0x000141e0 0x00000260 0x4200= 0040 DevicePathDxe.debug...reloc
  0x00000005 dwarf= -abbrev     [0x000000007f99a480-0x000000007f99bd09)&nbs= p; ---  0x00014440 0x000018a0 0x42000040 DevicePathDxe.debug= ...debug_abbrev
  0x00000006 dwarf-info  =     [0x000000007f99bd20-0x000000007f9ad8b7)  ---&= nbsp; 0x00015ce0 0x00011ba0 0x42000040 DevicePathDxe.debug...debug_inf= o
  0x00000007 dwarf-line      =  [0x000000007f9ad8c0-0x000000007f9bc1f7)  ---  0x0= 0027880 0x0000e940 0x42000040 DevicePathDxe.debug...debug_line
  0x00000008 dwarf-macinfo    [0x000000007f9bc20= 0-0x000000007f9bc223)  ---  0x000361c0 0x00000040 0x420= 00040 DevicePathDxe.debug...debug_macinfo
  0x00000= 009 dwarf-ranges     [0x000000007f9bc240-0x000000007f9b= e020)  ---  0x00036200 0x00001de0 0x42000040 DevicePath= Dxe.debug...debug_ranges
  0x0000000a dwarf-str&nbs= p;       [0x000000007f9be020-0x000000007f9cb099) &= nbsp;---  0x00037fe0 0x0000d080 0x42000040 DevicePathDxe.debug...= debug_str
=E2=80=A6
(lldb) i= mage dump symtab
Dumping symbol table for 90 modules.
Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/N= OOPT_CLANGPDB/X64/DxeCore.debug, num_symbols =3D 4343:
 =              Debug symbol
               |Synthetic symbol               ||Exter= nally Visible
             = ;  |||
Index   UserID DSX Type  &nbs= p;         File Address/Value Load Address &n= bsp;     Size            =   Flags      Name
------- ----= -- --- --------------- ------------------ ------------------ --------------= ---- ---------- ----------------------------------
[  &n= bsp; 0] 4294967295     Invalid     =     0x0000000000000000 0x000000007fe1b000 0x000000000000003a= 0x00000000 .text
[    1] 4294967295 &nbs= p;   Invalid         0x000000000000= 0000                   &n= bsp;0x0000000000000000 0x00000000 .data
[    2= ] 4294967295     Invalid       &nbs= p; 0x0000000000001898              =       0x0000000000000000 0x00000000 .bss
= [    3] 4294967295     Invalid &nbs= p;       0x0000000000046bc0 0x000000007fe61bc0 0x000000= 0000000374 0x00000000 .text$_ModuleEntryPoint
[   &= nbsp;4] 4294967295     Code        =     0x0000000000046bc0 0x000000007fe61bc0 0x0000000000000374= 0x00000000 _ModuleEntryPoint
[    5] 42949672= 95     Invalid         0x= 0000000000001b08                &nb= sp;   0x0000000000000000 0x00000000 .bss$gHobList
[=     6] 4294967295     Invalid  = ;       0x0000000000001b08        &= nbsp;           0x0000000000000000 0x00000000= gHobList
[    7] 4294967295    = ; Invalid         0x0000000000000000&nbs= p;                   0x00= 00000000000000 0x00000000 .rdata
[    8] 42949= 67295     Invalid         = ;0x0000000000000000                =     0x0000000000000000 0x00000000 .str
[ =   9] 4294967295     Invalid   &nbs= p;     0x0000000000000058          =           0x0000000000000000 0x00000000 .rdat= a
[   10] 4294967295     I= nvalid         0x0000000000000058   = ;                 0x0000000000= 000000 0x00000000 .str.1
[   11] 4294967295&nb= sp;    Invalid         0x00000= 00000000000                  &= nbsp; 0x0000000000000000 0x00000000 .debug_str
[ &n= bsp; 12] 4294967295     Invalid    =     0x0000000000000000          &n= bsp;         0x0000000000000000 0x00000000 .debug_= abbrev
[   13] 4294967295    &n= bsp;Invalid         0x0000000000000000  =                   0x00000= 00000000000 0x00000000 .debug_info
[   14] 429= 4967295     Invalid        &nb= sp;0x0000000000000000               = ;     0x0000000000000000 0x00000000 .debug_ranges
[   15] 4294967295     Invalid&nb= sp;        0x0000000000000000      =               0x0000000000000000 0x= 00000000 .debug_macinfo
[   16] 4294967295&nbs= p;    Invalid         0x000000= 0000000000                  &n= bsp; 0x0000000000000000 0x00000000 .debug_line
[ &n= bsp; 17] 4294967295     Code      &= nbsp;     0x000000000003f680 0x000000007fe5a680 0x0000000000= 000020 0x00000000 ProcessModuleEntryPointList
[  &n= bsp;18] 4294967295     Code        =     0x0000000000023130 0x000000007fe3e130 0x0000000000000020= 0x00000000 DebugAssertEnabled
[   19] 4294967= 295     Code           &n= bsp;0x0000000000023060 0x000000007fe3e060 0x00000000000000d0 0x00000000 Deb= ugAssert
[   20] 4294967295    =  Code            0x0000000000022150= 0x000000007fe3d150 0x0000000000000020 0x00000000 CpuDeadLoop
[   21] 4294967295     Invalid &nb= sp;       0x0000000000000000 0x000000007fe1b000 0x00000= 0000000003a 0x00000000 .text
[   22] 429496729= 5     Invalid         0x0= 000000000000000                &nbs= p;   0x0000000000000000 0x00000000 .data
[ &nb= sp; 23] 4294967295     Invalid     =     0x0000000000001898          &nb= sp;         0x0000000000000000 0x00000000 .bss
[   24] 4294967295     Invali= d         0x000000000003f240 0x000000007fe5a2= 40 0x0000000000000440 0x00000000 .text$ProcessLibraryConstructorList
[   25] 4294967295     Code = ;           0x000000000003f240 0x000000007fe5= a240 0x0000000000000440 0x00000000 ProcessLibraryConstructorList
[   26] 4294967295     Invalid&nb= sp;        0x000000000003f680 0x000000007fe5a680 0= x0000000000000020 0x00000000 .text$ProcessModuleEntryPointList
[   27] 4294967295     Invalid &n= bsp;       0x0000000000000070       = ;             0x0000000000000000 0x00000= 000 .data$gEfiCallerIdGuid
[   28] 4294967295&= nbsp;    Invalid         0x000= 0000000000070                 =   0x0000000000000000 0x00000000 gEfiCallerIdGuid
[=    29] 4294967295     Invalid  = ;       0x0000000000000148        &= nbsp;           0x0000000000000000 0x00000000= .data$gEfiEventMemoryMapChangeGuid
[   30] 42= 94967295     Invalid        &n= bsp;0x0000000000000148              &nbs= p;     0x0000000000000000 0x00000000 gEfiEventMemoryMapChang= eGuid
[   31] 4294967295    &nb= sp;Invalid         0x0000000000000168  &= nbsp;                 0x000000= 0000000000 0x00000000 .data$gEfiEventVirtualAddressChangeGuid
[   32] 4294967295     Invalid &nb= sp;       0x0000000000000168       =             0x0000000000000000 0x000000= 00 gEfiEventVirtualAddressChangeGuid
[   33] 4= 294967295     Invalid        &= nbsp;0x0000000000000138              &nb= sp;     0x0000000000000000 0x00000000 .data$gEfiEventExitBoo= tServicesGuid
[   34] 4294967295   &= nbsp; Invalid         0x0000000000000138=                     = 0x0000000000000000 0x00000000 gEfiEventExitBootServicesGuid
= =E2=80=A6.
[  303] 4294967295   &= nbsp; Invalid         0x0000000000001b60=                     = 0x0000000000000000 0x00000000 .bss$gST
[  304] 4294= 967295     Invalid        &nbs= p;0x0000000000001b60               =     0x0000000000000000 0x00000000 gST
[ =  305] 4294967295     Invalid     &n= bsp;   0x00000000000018a0           = ;         0x0000000000000000 0x00000000 .bss$gBS[  306] 4294967295     Invalid&n= bsp;        0x00000000000018a0     =               0x0000000000000000 0= x00000000 gBS
=E2=80=A6

<= /div>
=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 {
  Hdr =3D (Signature =3D 0x545359532049424= 9, Revision =3D 0x00020046, HeaderSize =3D 0x00000078, CRC32 =3D 0x5355dbe2= , Reserved =3D 0x00000000)
  FirmwareVendor =3D 0x0= 00000007fbe9c98
  FirmwareRevision =3D 0x00010000  ConsoleInHandle =3D 0x000000007ede5a98
  ConIn =3D 0x000000007e95f640
  Conso= leOutHandle =3D 0x000000007ede4e98
  ConOut =3D 0x0= 00000007e95f800
  StandardErrorHandle =3D 0x0000000= 07ede4b98
  StdErr =3D 0x000000007e95f910
  RuntimeServices =3D 0x000000007fbeeb98
&nb= sp; BootServices =3D 0x000000007fe6cde8
  Numb= erOfTableEntries =3D 0x0000000000000009
  Configura= tionTable =3D 0x000000007fbeec98
}
(lldb) = image lookup -Av --name gST
(lldb) image dump sectionsDumping sections for 88 modules.
Sections for '/= Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_XCODE5/X64/MdeModule= Pkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll' (x86_64):
  = ;SectID     Type          = ;   Load Address             &= nbsp;               Perm File Off.&= nbsp; File Size  Flags      Section Name=
  ---------- ---------------- --------------------= -------------------  ---- ---------- ---------- ---------- ------= ----------------------
  0x00000100 container =       [0x000000007fe26240-0x000000007fe6bb40) &nb= sp;r-x  0x000004a0 0x00045900 0x00000000 DxeCore.dll.__TEXT
  0x00000001 code          = ;   [0x000000007fe26240-0x000000007fe65bd8)  r-x &= nbsp;0x000004a0 0x0003f998 0x80000400 DxeCore.dll.__TEXT.__text
  0x00000002 data-cstr        [0x0000= 00007fe65bd8-0x000000007fe6ba23)  r-x  0x0003fe38 0x000= 05e4b 0x00000002 DxeCore.dll.__TEXT.__cstring
  0x0= 0000003 regular          [0x000000007fe6ba24-= 0x000000007fe6ba6c)  r-x  0x00045c84 0x00000048 0x00000= 000 DxeCore.dll.__TEXT.__ustring
  0x00000004 regul= ar          [0x000000007fe6ba70-0x000000007fe= 6bb40)  r-x  0x00045cd0 0x000000d0 0x00000000 DxeCore.d= ll.__TEXT.__const
  0x00000200 container  &nbs= p;     [0x000000007fe6bb40-0x000000007fe70e60)  rw= -  0x00045da0 0x00001ae0 0x00000000 DxeCore.dll.__DATA
  0x00000005 regular         &nbs= p;[0x000000007fe6bb40-0x000000007fe6bd58)  rw-  0x00045= da0 0x00000218 0x00000000 DxeCore.dll.__DATA.__const
 &n= bsp;0x00000006 data             [0x= 000000007fe6bd60-0x000000007fe6d610)  rw-  0x00045fc0 0= x000018b0 0x00000000 DxeCore.dll.__DATA.__data
  0x= 00000007 zero-fill        [0x000000007fe6d610-0x00= 0000007fe70e20)  rw-  0x00000000 0x00000000 0x00000001 = DxeCore.dll.__DATA.__common
  0x00000008 zero-fill&= nbsp;       [0x000000007fe70e20-0x000000007fe70e58)&nbs= p; rw-  0x00000000 0x00000000 0x00000001 DxeCore.dll.__DATA.= __bss
  0x00000100 container      &n= bsp; [0x000000000004b000-0x00000000000ef000)* rw-  0x0000100= 0 0x000a3a74 0x00000000 DxeCore.dll.__DWARF
  0x000= 00001 dwarf-line       [0x000000000004b000-0x00000= 000000723fb)* rw-  0x00001000 0x000273fb 0x00000000 DxeCore.dll._= _DWARF.__debug_line
  0x00000002 dwarf-pubnames&nbs= p;  [0x00000000000723fb-0x0000000000078429)* rw-  0x000= 283fb 0x0000602e 0x00000000 DxeCore.dll.__DWARF.__debug_pubnames
  0x00000003 dwarf-pubtypes   [0x0000000000= 078429-0x000000000008b915)* rw-  0x0002e429 0x000134ec 0x00000000= DxeCore.dll.__DWARF.__debug_pubtypes
  0x00000004 = dwarf-aranges    [0x000000000008b915-0x000000000008ea65)* rw= -  0x00041915 0x00003150 0x00000000 DxeCore.dll.__DWARF.__debug_a= ranges
  0x00000005 dwarf-info     &= nbsp; [0x000000000008ea65-0x00000000000c78bf)* rw-  0x00044a= 65 0x00038e5a 0x00000000 DxeCore.dll.__DWARF.__debug_info
&nb= sp; 0x00000006 dwarf-frame      [0x00000000000c78b= f-0x00000000000cc697)* rw-  0x0007d8bf 0x00004dd8 0x00000000 DxeC= ore.dll.__DWARF.__debug_frame
  0x00000007 dwarf-ra= nges     [0x00000000000cc697-0x00000000000cc757)* rw-&n= bsp; 0x00082697 0x000000c0 0x00000000 DxeCore.dll.__DWARF.__debug_rang= es
  0x00000008 dwarf-abbrev    &nbs= p;[0x00000000000cc757-0x00000000000cca9b)* rw-  0x00082757 0x0000= 0344 0x00000000 DxeCore.dll.__DWARF.__debug_abbrev
 &nbs= p;0x00000009 dwarf-str        [0x00000000000cca9b-= 0x00000000000dcc05)* rw-  0x00082a9b 0x0001016a 0x00000000 DxeCor= e.dll.__DWARF.__debug_str
  0x0000000a apple-names&= nbsp;     [0x00000000000dcc05-0x00000000000e2439)* rw- =  0x00092c05 0x00005834 0x00000000 DxeCore.dll.__DWARF.__apple_names  0x0000000b apple-namespaces [0x00000000000e2439-0x0= 0000000000e245d)* rw-  0x00098439 0x00000024 0x00000000 DxeCore.d= ll.__DWARF.__apple_namespac
  0x0000000c apple-type= s      [0x00000000000e245d-0x00000000000eea50)* rw-&nbs= p; 0x0009845d 0x0000c5f3 0x00000000 DxeCore.dll.__DWARF.__apple_types<= br class=3D"">  0x0000000d apple-objc      &n= bsp;[0x00000000000eea50-0x00000000000eea74)* rw-  0x000a4a50 0x00= 000024 0x00000000 DxeCore.dll.__DWARF.__apple_objc
Sections f= or '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_XCODE5/X64/MdeM= odulePkg/Universal/DevicePathDxe/DevicePathDxe/DEBUG/DevicePathDxe.dll' (x8= 6_64):
=E2=80=A6
(lldb) imag= e dump symtab
Dumping symbol table for 88 modules.
Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/N= OOPT_XCODE5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll, num_symbol= s =3D 1203:
              =  Debug symbol
            =    |Synthetic symbol
        &n= bsp;      ||Externally Visible
    &= nbsp;          |||
Index  =  UserID DSX Type            File Ad= dress/Value Load Address       Size   &n= bsp;           Flags      = ;Name
------- ------ --- --------------- ------------------ -= ----------------- ------------------ ---------- ---------------------------= -------
[    0]    118 D &= nbsp; SourceFile      0x0000000000000000  &nb= sp;                 Sibling -&= gt; [   20] 0x00640000 /Users/user/Documents/UefiPackag= es/MdeModulePkg/Core/Dxe/SectionExtraction/CoreSectionExtraction.c
[    1]    120 D   Obje= ctFile      0x000000005e78588d      &nbs= p;             0x0000000000000000 0x0066= 0001 /Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_XCODE5/X6= 4/MdeModulePkg/Core/Dxe/DxeMain/OUTPUT/DxeCore.lib(CoreSectionExtraction.ob= j)
[    2]    122 D X Code = ;           0x0000000000000240 0x000000007fe2= 6240 0x0000000000000260 0x000f0000 CustomGuidedSectionExtract
[    3]    126 D X Code      =       0x00000000000004a0 0x000000007fe264a0 0x000000000= 0000110 0x000f0000 InitializeSectionExtraction
[   =  4]    130 D X Code          &= nbsp; 0x00000000000005b0 0x000000007fe265b0 0x0000000000000140 0x000f0= 000 IsValidSectionStream
[    5]   &= nbsp;134 D X Code            0x000000000= 00006f0 0x000000007fe266f0 0x0000000000000180 0x000f0000 OpenSectionStreamE= x
[    6]    138 D X Code =           0x0000000000000870 0x000000007fe26= 870 0x0000000000000070 0x000f0000 OpenSectionStream
[  &= nbsp; 7]    142 D X Code        &nb= sp;   0x00000000000008e0 0x000000007fe268e0 0x0000000000000100 0x= 000f0000 ChildIsType
=E2=80=A6
[ &n= bsp;831]   2470 D X Code          &= nbsp; 0x00000000000306b0 0x000000007fe566b0 0x00000000000000f4 0x000f0= 000 UefiBootServicesTableLibConstructor
[  832]&nbs= p;  2473 D X Data            0= x0000000000047780 0x000000007fe6d780 0x0000000000000008 0x000f0000 gImageHa= ndle
[  833]   2474 D X Data  &= nbsp;         0x0000000000047788 0x000000007fe6d78= 8 0x0000000000000008 0x000f0000 gST
[  834] &n= bsp; 2475 D X Data            0x000= 0000000047790 0x000000007fe6d790 0x0000000000000008 0x000f0000 gBS
=E2=80=A6

This is easy en= ough to check as %rpb is the frame pointer so it will get saved/restored on= function entry/exit. 

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 s= oon reached 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

Best wis= hes,
Vitaly

=
[1] https://github.com/acid= anthera/OpenCorePkg/blob/7684a9f/Debug/ClangDwarf.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/a= cidanthera/OpenCorePkg/commit/3e5f3f3f9a8d3f197834bbfcf5029f771df89754<= br class=3D"">

22 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0=B2 00:06, A= ndrew Fish <afish@apple.co= m> =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 Cheptsov <cheptsov@ispras.ru> wrote:
Andrew,

Thanks once again, but unfortunately it is n= ot that simple. = Below I answered inline explaining the particular issues, which mostly seem= to be specific to CLANGPDB. LLV= M stack emits PDB debug files, and even though LLDB does support them to so= me level, it is unlikely that this will be working well enough soon. We sho= uld really stick to more or less native debug formats, ideally those that h= ave proper open specifications, on all platforms, and for Unix that=E2=80= =99s DWARF.

Vitaly,

I understand and I use the Xcode clang and not the CL= ANGPDB, but I use lldb a lot I was just trying to point out what works with= Xcode. 

<= /div>
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 em= it dwarf. Not sure what that compiler flag would do to CLANGPDB but it is w= orth a try? Last flag wins for the compiler. 

You can teach lldb about types. T= here is some example code here: https://github.c= om/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py

This code works just fine with LL= DB and DWARF (e.g. XCODE5), though I have not yet completed these changes f= or my scripts for LLDB, only for GDB. However, with CLANGPDB generated file= s it is not functional. The reason for this is because LLDB is unaware of t= he underlying type, i.e. it does not know what is EFI_STATUS or UINT32. I c= an 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 pars= ed:

(lldb) p Status
(unsigned = long long) $1 =3D 0
(lldb) p &Status
(unsig= ned long long *) $2 =3D 0x000000007fe19ad8
(lldb) p (EFI_STAT= US)Status
error: use of undeclared identifier 'EFI_STATUS'

<= /div>
= Just in case I tried using exactly your code, and other stuff like source l= evel debugging works just fine and symbolication works fine, so it should b= e some bug with PDB in particular.

That is s= trange 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 zero and reloca= ted into memory, so the slide represents that adjustment. 

You can use `image dump sect= ions` and ` image dump symtab` to see lldb's view of symbols. More inf= o here [1]. 

Ye= s, this one is a bit complicated, once again due to PDB most likely. It kno= ws about global symbols, but does not list them in symtab:

(lldb) image dump symtabDumping symbol table for 91 modules.
Symtab, fil= e =3D GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll, num_symbols =3D 0
Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_C= LANGPDB/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll, num_symbols = =3D 0
Symtab, file =3D /Users/user/Documents/UefiWorkspace/B= uild/OvmfX64/NOOPT_CLANGPDB/X64/MdeModulePkg/Universal/DevicePathDxe/Device= PathDxe/DEBUG/DevicePathDxe.dll, num_symbols =3D 0
=E2= = =80=A6

The slide= s are correct, but there are two nuances that collide with it.

1. There are multiple instanc= es of the globals with the same name (e.g. gBS), but for some reason LLDB a= lways tries to print the globals from the first module. This happens even w= hen 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 from the first module. I tried che= cking expr help to find whether I can pass it a module explicitly, but also= failed.


Usually what happens with lldb is you get the gl= obal that is in scope for the current frame. 

2.  To be able to get EFI types t= o locate the EFI_SYSTEM_TABLE_POINTER I add a dummy GdbSyms image, which is= not loaded 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 i= t failed for me.


I've not used the fake image to get thin= gs done so I can't speak to that. I have used a fake target so I could have= XIP PEIM and shadowed PEIM address available at the same time. You can't h= ave a module loaded at 2 addresses at the same time in llldb. But you might= be able to use a fake target for your fake stuff?

Just in case:

 =         # create a faka target to store info about sym= bols
          PeiXipTarget = =3D target.debugger.CreateTarget (None, "i386-apple-macosx", "remote-macos= x", True, error)

=           # make sure the gdb-remote  connect= ion target is the active target
      &= nbsp;   target.debugger.SetSelectedTarget (target)


(lldb) image dump sections
Dumping sect= ions for 91 modules.
Sections for 'GdbSyms/Bin/X64_CLANGPDB/G= dbSyms.dll' (x86_64):
  SectID    &n= bsp;Type             Load Address&n= bsp;                    &= nbsp;       Perm File Off.  File Size &n= bsp;Flags      Section Name
  -= --------- ---------------- --------------------------------------- &nb= sp;---- ---------- ---------- ---------- ----------------------------
  0xffffffffffffffff container       = ; [0x0000000000000000-0x0000000000006ec0)* ---  0x00000000 0= x00000000 0x00000000 GdbSyms.dll.
  0x00000001 code=              [0x0000000000000220-0x= 0000000000005bd6)* ---  0x00000220 0x000059c0 0x60000020 GdbSyms.= dll...text
  0x00000002 data     &nb= sp;       [0x0000000000005be0-0x0000000000006d79)* ---&= nbsp; 0x00005be0 0x000011a0 0x40000040 GdbSyms.dll...rdata
  0x00000003 data           &nbs= p; [0x0000000000006d80-0x0000000000006e30)* ---  0x00006d80 = 0x00000060 0xc0000040 GdbSyms.dll...data
  0x000000= 04 regular          [0x0000000000006e40-0x000= 0000000006ea4)* ---  0x00006de0 0x00000080 0x42000040 GdbSyms.dll= ...reloc
Sections for '/Users/user/Documents/UefiWorkspace/Bu= ild/OvmfX64/NOOPT_CLANGPDB/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.= dll' (x86_64):
  SectID     Typ= e             Load Address &nb= sp;                     &= nbsp;     Perm File Off.  File Size  Fla= gs      Section Name
  --------= -- ---------------- ---------------------------------------  ----= ---------- ---------- ---------- ----------------------------
  0xffffffffffffffff container        = [0x0000000000000000-0x00000000000523a0)* ---  0x00000000 0x000000= 00 0x00000000 DxeCore.dll.
  0x00000001 code &= nbsp;           [0x000000007fe1b220-0x0000000= 07fe61e34)  ---  0x00000220 0x00046c20 0x60000020 DxeCo= re.dll...text
  0x00000002 data     =         [0x000000007fe61e40-0x000000007fe68065)&nb= sp; ---  0x00046e40 0x00006240 0x40000040 DxeCore.dll...rdat= a
  0x00000003 data        = ;     [0x000000007fe68080-0x000000007fe6d160)  ---=   0x0004d080 0x000018a0 0xc0000040 DxeCore.dll...data
  0x00000004 regular          [0= x000000007fe6d160-0x000000007fe6d398)  ---  0x0004e920 = 0x00000240 0x42000040 DxeCore.dll...reloc
Sections for '/User= s/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_CLANGPDB/X64/MdeModulePk= g/Universal/DevicePathDxe/DevicePathDxe/DEBUG/DevicePathDxe.dll' (x86_64):<= br class=3D"">  SectID     Type   &= nbsp;         Load Address     &nbs= p;                     &n= bsp; Perm File Off.  File Size  Flags   =   Section Name
  ---------- ------------= ---- ---------------------------------------  ---- ---------- ---= ------- ---------- ----------------------------
  0= xffffffffffffffff container        [0x000000000000= 0000-0x0000000000014420)* ---  0x00000000 0x00000000 0x00000000 D= evicePathDxe.dll.
  0x00000001 code   &nb= sp;         [0x000000007f986220-0x000000007f996cc6= )  ---  0x00000220 0x00010ac0 0x60000020 DevicePathDxe.= dll...text
  0x00000002 data     &nb= sp;       [0x000000007f996ce0-0x000000007f999b04) =  ---  0x00010ce0 0x00002e40 0x40000040 DevicePathDxe.dll...r= data
  0x00000003 data       &n= bsp;     [0x000000007f999b20-0x000000007f99a1a2)  = ---  0x00013b20 0x00000660 0xc0000040 DevicePathDxe.dll...data  0x00000004 regular         = ; [0x000000007f99a1c0-0x000000007f99a404)  ---  0x= 00014180 0x00000260 0x42000040 DevicePathDxe.dll=E2=80=A6reloc
=E2=80=A6

So, a= ll in all, unique global variables work, but there is no way to access dupl= icating variables. They either resolve to GdbSyms or just cause a crash:

(lldb) p mDebu= gInfoTableHeader
(EFI_DEBUG_IMAGE_INFO_TABLE_HEADER) $0 =3D {=
  UpdateStatus =3D 2
  Tab= leSize =3D 92
  EfiDebugImageInfoTable =3D 0x000000= 007f814018
}
(lldb) p gBS
er= ror: Couldn't materialize: couldn't get the value of variable ::gBS: read m= emory from 0x6df8 failed
error: errored out in DoExecute, cou= ldn't PrepareToExecuteJITExpression
(lldb) p gEfiGlobalV= ariableGuid
0  libLLVM.dylib      &n= bsp;     0x000000010e52ee68 llvm::sys::PrintStackTrace(llvm:= :raw_ostream&) + 40
1  libLLVM.dylib  &nbs= p;         0x000000010e52f262 SignalHandler(int) += 188
2  libsystem_platform.dylib 0x00007fff6ca5642d= _sigtramp + 29
...


If you want to inspect= globals I think this logic works to get you data, you would need to print = it out etc. 

SBValueList =3D lldb.targe= t.FindGlobalVariables ("gST", 1024)
for SBValue in SBValueList:
M= odule =3D SBValue.GetAddress().GetModule() 
        ModuleStr =3D SBValue.GetAdd= ress().GetModule().GetFileSpec().GetFilename()
        Start =3D int (SBValue.GetL= ocation(), 0)
    &n= bsp;   End =3D Start + SBValue.GetByteSize() - 1
        SBDeclaration =3D SBValue.GetDeclaration()
&nbs= p;       Column =3D SBDeclaration.GetColumn()

<= /div>
I wrote a command in 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 write c= om.apple.dt.lldb DefaultPythonVersion 2

Thanks, that helped quite a bit, but for some reason Xc= ode 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 abou= t the PDB plugin.

For the macOS API cla= ng emits frame pointers, so you can walk the stack without symbols. You cou= ld try adding the compiler flag to emit the frame pointers. 

<= /div>

This is easy enough to= check as %rpb is the frame pointer so it will get saved/restored on functi= on entry/exit. 

I am pretty sure stack frames are not disabled with = UEFI, as sometimes backtracing works just fine. To me it looks like debug i= nformation parsing randomly breaks in LLDB, and once it happens it forgets = about other images:

(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    EFI_STATUS    =       Status;
   647    U= INTN               BufferSize;=
   648 
-> 649    if&nbs= p;(NumberHandles =3D=3D NULL) {
   650     &n= bsp;return EFI_INVALID_PARAMETER;
   651 =  &n= bsp;}
   652 
(lldb) bt
* thread #1, stop reason =3D breakpoint 2.1
 &nb= sp;* frame #0: 0x000000007fe36e4f DxeCore.dll`CoreLocateHandleBuf= fer(SearchType=3DByProtocol, Protocol=3D0x000000007f978160, SearchKey=3D0x0= 000000000000000, NumberHandles=3D0x000000007fe19fd8, Buffer=3D0x000000= 007fe19fc0) at Locate.c:649
    frame #1:=  0x000000007fe36816 DxeCore.dll`CoreLocateDevicePath(Protocol=3D0= x000000007f978160, DevicePath=3D0x000000007fe1a060, Device=3D0x000000007fe1= a068) at Locate.c:466
    frame #2: = 0x000000007f97479a SecurityStubDxe.dll

=E2=80=94=E2=80=94=E2=80=94

(lldb) b CopyMem
Breakpoint 3: 7= 0 locations.
(lldb) c
Process 1 resumingProcess 1 stopped
* thread #1, stop reason =3D&n= bsp;breakpoint 2.53 3.53
    frame #0: 0x= 000000007e5c13b3 MnpDxe.dll`CopyMem(DestinationBuffer=3D0x000000007fe1= 9b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at CopyMemWrapp= er.c:47
   44     IN UINTN   &= nbsp;   Length
   45     )
   46   {
-> 47     if&= nbsp;(Length =3D=3D 0) {
   48      = ; return DestinationBuffer;
   49 &n= bsp; &nbs= p; }
   50     ASSERT ((Length -&nb= sp;1) <=3D (MAX_ADDRESS - (UINTN)DestinationBuffer));
(lld= b) bt
* thread #1, stop reason =3D breakpoint 2.53 = 3.53
  * frame #0: 0x000000007e5c13b3 Mnp= Dxe.dll`CopyMem(DestinationBuffer=3D0x000000007fe19b50, SourceBuffer=3D0x00= 0000007e2aa470, Length=3D656) at CopyMemWrapper.c:47
(ll= db) finish
error: Could not create return address breakp= oint.
(lldb) n
Process 1 stopped
* thread #1, stop reason =3D step over
  &nb= sp; frame #0: 0x000000007e5c13ce MnpDxe.dll`CopyMem(Destinat= ionBuffer=3D0x000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length= =3D656) at CopyMemWrapper.c:50
   47 &nb= sp;  = ; if (Length =3D=3D 0) {
   48 =   &n= bsp;   return DestinationBuffer;
   = 49   <= /span>  }
-> 50     ASSERT ((Length -=  1) <=3D (MAX_ADDRESS - (UINTN)DestinationBuffer));
&= nbsp;  51     ASSERT ((Length - 1) <=3D (MAX_ADDRES= S - (UINTN)SourceBuffer));
   52  
=    53     if (DestinationBuffer =3D=3D SourceBuff= er) {
(lldb)  
...
Proc= ess 1 stopped
* thread #1, stop reason =3D step over
    frame #0: 0x000000007e5c14b4 MnpDxe= .dll`CopyMem(DestinationBuffer=3D0x000000007fe19b50, SourceBuffer=3D0x00000= 0007e2aa470, Length=3D656) at CopyMemWrapper.c:57
 =  54       return DestinationBuffer;
   55     }
   56  = ;  &= nbsp;return InternalMemCopyMem (DestinationBuffer, SourceBuffer, Lengt= h);
-> 57   }
(lldb)  
Process 1 stopped
* thread #1, stop reason =3D st= ep over
    frame #0: 0x000000007e5c726e&= nbsp;MnpDxe.dll
->  0x7e5c726e: mov   =  rax, qword ptr [rsp + 0x60]
    0x7e5c72= 73: cmp    byte ptr [rax + 0x68], 0x0
  &= nbsp; 0x7e5c7277: jne    0x7e5c7291
 = ;   0x7e5c727d: movabs rax, -0x7fffffffffffffed
(ll= db) bt
* thread #1, stop reason =3D step over
  * frame #0: 0x000000007e5c726e&nb= sp;MnpDxe.dll 

=E2=80=94=E2=80=94=E2=80=94

(lldb) c
Process 1 resuming
Process 1 stopped
* thread #1, stop reason =3D si= gnal SIGINT
    frame #0: 0x000000007fe4d= 72e DxeCore.dll
->  0x7fe4d72e: cmp  &= nbsp; al, 0x0
    0x7fe4d730: je &nb= sp;   0x7fe4d765
    0x7fe4d736: mov=     rcx, qword ptr [rsp + 0x20]
   &= nbsp;0x7fe4d73b: call   0x7fe4c4b0
(lldb) = ;bt
* thread #1, stop reason =3D signal SIGINT
  * frame #0: 0x000000007fe4d72e DxeCore.dll

On macOS the Mach-O and dSYM have a UUID (= dwarfdump -u) that is indexed by Spotlight (mdfind "com_apple_xcode_dsym_uu= ids =3D=3D *") [2]
This should be the UUID in the debu= g directory entry and you can use that to lookup the symbols like this:

module =3D target.Ad= dModule (None, None, uuid)
SBError =3D target.SetModul= eLoadAddress (module, LoadAddress + TeAdjust)

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)
<= div class=3D"" style=3D"margin: 0px; font-stretch: normal; font-size: 11px;= line-height: normal; font-family: Menlo;">Help on method AddModule in module = lldb:
<= span class=3D"" style=3D"font-variant-ligatures: no-common-ligatures;">AddM= odule(self, *args) method of lldb.SBTarget instance
    AddModule(SBTarget self, SBMo= dule module) -> bool
    AddModule(SBTarget self, char const * pa= th, char const * triple, char const * uuid_cstr, char const * symfile) ->= ; SBModule
  &nbs= p; AddModule(SBTarget self, SBModuleSpec module_spec) -> SBModule=

The minimum &= nbsp;you need to symbolicate a frame is uuid, LoadAddress, and PC. 

[1]&nb= sp;http://lldb.llv= m.org/use/map.html
[2] http://lldb.llvm.org/use/symbols.htm= l

Thanks for the= links again. Yes, I am using some of these, and in fact for GDB that=E2=80= = =99s pretty much what I did when I worked with XCODE5. It is very likely t= hat 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 wil= l only help myself, but not other people with e.g. Linux or people that wan= t me to use the same compiler with them.

Thanks for looki= ng out for others. 

Thanks,

Andrew Fish

Best regards,
Vitaly


<= /div>
2= 1 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0=B2 20:13, Andrew Fish &l= t;afish@apple.com> =D0= = =BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):



<= div class=3D"">On Mar 21, 2020, at 3:28 AM, Vitaly Cheptsov <cheptsov@ispras.ru> wrote:
Hello,

Andrey, thanks for the hint, it was very hel= pful. 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 c= lose to terrible. I may certainly 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 tools my conclusion is that LLDB is simply not su= ited for UEFI PDB debugging, and we really want DWARF  as there is no = other opensource debugger that supports PDB on macOS and Linux

In case somebody knows workarounds here are the issues = I faced:

=
1. All integer alias typedefs are d= iscarded in favour of underlying types. This way EFI_STATUS and EFI_TPL bec= ome unsigned long long, CHAR8 becomes char, and CHAR16 becomes unsigned sho= rt. It does not look like LLDB has the original types anywhere at all, and = it also does not have them registered.

 = ;   frame #0: 0x000000007fe242aa DxeCore.dll`CoreAlloca= tePoolPagesI(PoolType=3DEfiBootServicesData, NoPages=3D1, Granularity=3D409= 6, NeedGuard=3D'\0') at Pool.c:322
   319 = ;   =   return NULL;
   320    }
   321 
-> 322    Buffer =3D CoreA= llocatePoolPages (PoolType, NoPages, Granularity, NeedGuard);
   323    CoreReleaseMemoryLock ();
  &= nbsp;324  <= /span>
   325    if (Buffer !=3D NULL) {=
(lldb) p Status
(unsigned long long) $3 = =3D 0

Structures work more or less fine, but for simpler types l= ike strings we are out of even potential pretty-printing.

=

Vitaly,

You can te= ach lldb about types. There is some example code here: https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbe= fi.py

2. Glo= bal variables are not accessible. I am not sure what happens, but they eith= er seem to not relocate or conflict with the other names:

(lldb) p gST
error: Couldn't materia= lize: couldn't get the value of variable ::gST: read memory from 0x6e18 fai= led
error: errored out in DoExecute, couldn't PrepareToExecut= eJITExpression
(lldb) p &gST
error: Co= uldn't materialize: couldn't get the value of variable ::gST: read memory f= rom 0x6e18 failed
error: errored out in DoExecute, couldn't P= repareToExecuteJITExpression
<= br class=3D"">

That is st= range as globals usually work best? The common issue I've seen is getting t= he slide wrong. The EFI modules are linked at a value near zero and relocat= ed into memory, so the slide represents that adjustment. 

You can use `image dump sections` and ` image dump= symtab` to see lldb's view of symbols. More info here [1]. 

3. Quite a number of cras= hes.

In most cases autocompletion by tab pre= ss causes a crash. E.g.

b I<TAB>
=

So will do printing of a GUID, e.g. p gEfiGlobalVar= iableGuid.

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.


You can tell lldb to use the older Python like this (fr= om the Terminal.app):
$ d= efaults write com.apple.dt.lldb DefaultPythonVersion 2

<= div class=3D"" style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight= : normal; letter-spacing: normal; text-align: start; text-indent: 0px; text= -transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stro= ke-width: 0px; text-decoration: none;">4. Ctrl+C does not produce a valid backtrac= e. When I break 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 some weird backtrace with most of the entries missing regardless = of frame position:

(lldb) bt
* thread #1, stop re= ason =3D signal SIGTRAP
  * frame #0: 0x0= 00000007fe4c5f3 DxeCore.dll

Probably more and all the unintuitive stuff like the lack of more= functional TUI, but it is hard to remember all the trials.


For the macOS API clang emits frame pointers= , so you can walk the stack without symbols. You could try adding the compi= ler flag to emit the frame pointers. 

<= br class=3D"">
[1] h= ttps://github.com/acidanthera/OpenCorePkg/blob/master/Debug/Scripts/lldb_ue= fi.py


=
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]

module =3D= target.AddModule (None, None, uuid)
SBError =3D target.SetModuleLoadAddress (module, LoadAddress + TeAdj= ust)

Also lldb has built in help for command= s, but it is kind of terse since it is autogenerated from the C++ swig.&nbs= p;
(lldb) script help (lldb.target.AddModule)
=
Help on method AddModule in module= lldb:

= Add= Module(self, *args) method of lldb.SBTarget instance
    AddModule(SBTarget self, SBMo= dule module) -> bool
    AddModule(SBTarget self, char const * pa= th, char const * triple, char const * uuid_cstr, char const * symfile) ->= ; SBModule
  &nbs= p; AddModule(SBTarget self, SBModuleSpec module_spec) -> SBModule=

The minimum &= nbsp;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,

Andrew Fish

Best wishes,
Vitaly

20 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0= =B2 22:14, Andrew Fish <a= fish@apple.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):<= /div>


On Mar 20, 2020, at 8:13 AM, Vitaly= Cheptsov <cheptsov@isp= ras.ru> wrote:

Hello,

We noticed that the original bugzilla, which intende= d to add new LLVM toolchain support[1], also wanted to bring ELF format sup= port with DWARF debugging information. For some reason this did not make its way into EDK I= I, and we are currently wondering, how can one debug binaries built with LL= VM 9.0.

For macOS and XCODE5 toolchain we use= GDB scripts based on Andrei Warkentin=E2=80= =99s work, which allow us to integrate with QEMU and VMware[2]. It is like= ly that they should work with little to no work on Linux with CLANG38/GCC5 = with GDB once again. However, CLANGPDB apparently is using PDB debugging in= formation, which I believe is not handled with GDB.

Could you please provide the de= tails on the matter and let us know about the recommended route?
=E2=80=94 Is dropping CLANGELF just a temporary measure and it s= hould be resubmitted again?
=E2=80=94 Should LLDB, which seems to be = aware of PDB, be used instead of GDB, when building with CLANGPDB? If so, d= id anybody try that?


Vitaly,

I've= not tried the CLANGPDB path, but if you want to connect lldb to QEMU you n= eed to set  plugin.process.gdb-remote.target-definition-file [1] to [2= ]. 

=
[1]  lldb -o "settings se= t plugin.process.gdb-remote.target-definition-file x86_64_target_definition= .py" -o "gdb-remote 9000"
[2]<= span class=3D"Apple-converted-space"> https://github.com/llvm-mirror/lldb/blob/master/examples/pyt= hon/x86_64_target_definition.py

Thanks,<= /div>

Andrew Fish

Thanks!

Best re= gards,
Vitaly

[1] https://bugzilla.tia= nocore.org/show_bug.cgi?id=3D1603
[2] https://github.com/acidanthera/OpenCorePkg/blob/mast= er/Debug/Scripts/gdb_uefi.py

=


<= ;crashes.txt>
--Apple-Mail=_3A9DFBBC-1A3D-40F3-A555-21D0D51CC107-- --Apple-Mail=_750CC4C3-238E-4A77-B88F-D079B932DB45 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----- iQIzBAEBCgAdFiEEsLABAI5Y5VbvBdmpL8K2O86Eyz4FAl54fPYACgkQL8K2O86E yz7zjw//f/LG+EL2mrk9gbDTPiYlvnSD9lFAGo0FS4ZhWm7Zkg9OaBIl2e6gkzFY YXPWg+GfHOiW2lst8Mj35Pivdg0WBWGHFH6Qz2OSd3RrHvJFFOswqhyTYK8krOKJ AM0bCdPb21vQD3xABdFfZK655fU0Fy9Ns/V8BwTVuVGbWwJ+1ttj4hVG2rixMBAE m1hiRBTbUyHbg+s2/frvkR2SiHAkMediSSS+2JyjnOOoyC9LhImsXkpkhaOyYWGu 7AUk+GwF7fxIyVriiyERm2A7/bMBvY6qJNJpVlhv7Ec72+QnqNNz1qKPLhynpDDU uH9tF7cCn6nxoi8CsUAportcP7XnW4YZnyxa9+7uIqsM8/s7Fwp92XlP280ffzbA tpaWDvDscMk142E0I/KX8MntJH1Ck35ppVPurKB0uMJMRQtU6zNJgowIvQMErM7s h/QCi2o2rSCn4XyLlfyvjelZbEAJVQr8n5LoAZzzKhPl9KVsktiDxuu/OB8auxhY KockFC3xCzHM1Mb/b1ohlcTnPpT/KcXDR8zLZOkuMemk8syV+ozjkH7rSZPyO76a sMOpdybSncV+Nf9dXuuLRQRD6/A+BE75IlUJbTkavVemN9k4BKTvuFydIqFGgget cGuypVp/52CzSsMqNgmPlTy8X4Y+EVgfL/LvBAECaQm/VVNQhhU= =lHCL -----END PGP SIGNATURE----- --Apple-Mail=_750CC4C3-238E-4A77-B88F-D079B932DB45--