From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.45]) by mx.groups.io with SMTP id smtpd.web12.14493.1584815782028791918 for ; Sat, 21 Mar 2020 11:36:23 -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 CC5DD653; Sat, 21 Mar 2020 21:36:19 +0300 (MSK) From: "Vitaly Cheptsov" Message-Id: <5C8DD065-0140-428B-A146-999A5694BC99@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: Sat, 21 Mar 2020 21:36:18 +0300 In-Reply-To: <63396616-D8CF-4135-B967-772C1E6136BD@apple.com> Cc: devel@edk2.groups.io, "Gao, Liming" , =?utf-8?Q?Marvin_H=C3=A4user?= To: Andrew Fish References: <9804C565-0C9E-4778-92A7-06EA6AD8D694@ispras.ru> <7E18AD8F-9A44-45FE-A8C8-CE06A6328930@apple.com> <63396616-D8CF-4135-B967-772C1E6136BD@apple.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Groupsio-MsgNum: 56072 Content-Type: multipart/signed; boundary="Apple-Mail=_70470479-C16E-41AA-96F6-03AE5C2D084B"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_70470479-C16E-41AA-96F6-03AE5C2D084B Content-Type: multipart/alternative; boundary="Apple-Mail=_31023E76-662B-42F5-90E8-486884B65E56" --Apple-Mail=_31023E76-662B-42F5-90E8-486884B65E56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Andrew, Thanks once again, but unfortunately it is not that simple. Below I answer= ed inline explaining the particular issues, which mostly seem to be specifi= c to CLANGPDB. LLVM stack emits PDB debug files, and even though LLDB does = support them to some level, it is unlikely that this will be working well e= nough soon. We should really stick to more or less native debug formats, id= eally those that have proper open specifications, on all platforms, and for= Unix that=E2=80=99s DWARF. I am pretty sure LLVM can be taught to emit DWARF debug information even f= or PE files. Perhaps we can either make some option or provide a separate t= oolchain for this? Another way would be recovering CLANGELF as originally s= uggested. > 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 have= not yet completed these changes for my scripts for LLDB, only for GDB. How= ever, with CLANGPDB generated files it is not functional. The reason for th= is is because LLDB is unaware of the underlying type, i.e. it does not know= what is EFI_STATUS or UINT32. I can implement pretty-printing when LLDB kn= ows about a typedef, but it is not possible to do this when the debug infor= mation is already gone or not parsed: (lldb) p Status (unsigned long long) $1 =3D 0 (lldb) p &Status (unsigned long long *) $2 =3D 0x000000007fe19ad8 (lldb) p (EFI_STATUS)Status error: use of undeclared identifier 'EFI_STATUS' Just in case I tried using exactly your code, and other stuff like source = level debugging works just fine and symbolication works fine, so it should = be some bug with PDB in particular. > That is strange as globals usually work best? The common issue I've seen= is getting the slide wrong. The EFI modules are linked at a value near zer= o and relocated into memory, so the slide represents that adjustment. >=20 > You can use `image dump sections` and ` image dump symtab` to see lldb's= view of symbols. More info here [1]. 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: (lldb) image dump symtab Dumping symbol table for 91 modules. Symtab, file =3D GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll, num_symbols =3D 0 Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_C= LANGPDB/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll, num_symbols = =3D 0 Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_C= LANGPDB/X64/MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe/DEBUG/Device= PathDxe.dll, num_symbols =3D 0 =E2=80=A6 The slides are correct, but there are two nuances that collide with it. 1. There are multiple instances of the globals with the same name (e.g. gB= S), but for some reason LLDB always tries to print the globals from the fir= st module. This happens even when I am source-level debugging, and I see a = gBS symbol from another module (e.g. DxeCore) used right at the same line. = With GDB the closest symbol is used, but with LLDB it is always coming from= the first module. I tried checking expr help to find whether I can pass it= a module explicitly, but also failed. 2. To be able to get EFI types to locate the EFI_SYSTEM_TABLE_POINTER I a= dd 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 it failed for me. (lldb) image dump sections Dumping sections for 91 modules. Sections for 'GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll' (x86_64): SectID Type Load Address Per= m File Off. File Size Flags Section Name ---------- ---------------- --------------------------------------- ---= - ---------- ---------- ---------- ---------------------------- 0xffffffffffffffff container [0x0000000000000000-0x0000000000006e= c0)* --- 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_CLAN= GPDB/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll' (x86_64): SectID Type Load Address Per= m File Off. File Size Flags Section Name ---------- ---------------- --------------------------------------- ---= - ---------- ---------- ---------- ---------------------------- 0xffffffffffffffff container [0x0000000000000000-0x00000000000523= a0)* --- 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_CLAN= GPDB/X64/MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe/DEBUG/DevicePat= hDxe.dll' (x86_64): SectID Type Load Address Per= m File Off. File Size Flags Section Name ---------- ---------------- --------------------------------------- ---= - ---------- ---------- ---------- ---------------------------- 0xffffffffffffffff container [0x0000000000000000-0x00000000000144= 20)* --- 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 So, all in all, unique global variables work, but there is no way to acces= s duplicating variables. They either resolve to GdbSyms or just cause a cra= sh: (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: rea= d memory from 0x6df8 failed error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression (lldb) p gEfiGlobalVariableGuid 0 libLLVM.dylib 0x000000010e52ee68 llvm::sys::PrintStackTrace(= llvm::raw_ostream&) + 40 1 libLLVM.dylib 0x000000010e52f262 SignalHandler(int) + 188 2 libsystem_platform.dylib 0x00007fff6ca5642d _sigtramp + 29 ... > You can tell lldb to use the older Python like this (from the Terminal.a= pp): > $ defaults write com.apple.dt.lldb DefaultPythonVersion 2 Thanks, that helped quite a bit, but for some reason Xcode version still c= rashes more for me. I attached a couple of stack traces if you feel like ha= ving a look, but once again it seems that it is all about the PDB plugin. > For the macOS API clang emits frame pointers, so you can walk the stack = without symbols. You could try adding the compiler flag to emit the frame p= ointers. I am pretty sure stack frames are not disabled with UEFI, as sometimes bac= ktracing works just fine. To me it looks like debug information parsing ran= domly 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 0x000000007fe36e4f (lldb) c Process 1 resuming Process 1 stopped * thread #1, stop reason =3D breakpoint 2.1 frame #0: 0x000000007fe36e4f DxeCore.dll`CoreLocateHandleBuffer(Search= Type=3DByProtocol, Protocol=3D0x000000007f978160, SearchKey=3D0x00000000000= 00000, 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(Search= Type=3DByProtocol, Protocol=3D0x000000007f978160, SearchKey=3D0x00000000000= 00000, NumberHandles=3D0x000000007fe19fd8, Buffer=3D0x000000007fe19fc0) at = Locate.c:649 frame #1: 0x000000007fe36816 DxeCore.dll`CoreLocateDevicePath(Protocol= = =3D0x000000007f978160, DevicePath=3D0x000000007fe1a060, Device=3D0x0000000= 07fe1a068) at Locate.c:466 frame #2: 0x000000007f97479a SecurityStubDxe.dll =E2=80=94=E2=80=94=E2=80=94 (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=3D0x= 000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at CopyM= emWrapper.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)DestinationBuffe= r)); (lldb) bt * thread #1, stop reason =3D breakpoint 2.53 3.53 * frame #0: 0x000000007e5c13b3 MnpDxe.dll`CopyMem(DestinationBuffer=3D0x= 000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at CopyM= emWrapper.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=3D0x= 000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at CopyM= emWrapper.c:50 47 if (Length =3D=3D 0) { 48 return DestinationBuffer; 49 } -> 50 ASSERT ((Length - 1) <=3D (MAX_ADDRESS - (UINTN)DestinationBuffe= r)); 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=3D0x= 000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at CopyM= emWrapper.c:57 54 return DestinationBuffer; 55 } 56 return InternalMemCopyMem (DestinationBuffer, SourceBuffer, Leng= th); -> 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 =E2=80=94=E2=80=94=E2=80=94 (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 > On macOS the Mach-O and dSYM have a UUID (dwarfdump -u) that is indexed = by Spotlight (mdfind "com_apple_xcode_dsym_uuids =3D=3D *") [2] > This should be the UUID in the debug directory entry and you can use tha= t to lookup the symbols like this: >=20 > module =3D target.AddModule (None, None, uuid) > SBError =3D target.SetModuleLoadAddress (module, LoadAddress + TeAdjust) >=20 > Also lldb has built in help for commands, but it is kind of terse since = it is autogenerated from the C++ swig. > (lldb) script help (lldb.target.AddModule) > Help on method AddModule in module lldb: >=20 > AddModule(self, *args) method of lldb.SBTarget instance > AddModule(SBTarget self, SBModule module) -> bool > AddModule(SBTarget self, char const * path, char const * triple, cha= r const * uuid) -> SBModule > AddModule(SBTarget self, char const * path, char const * triple, cha= r const * uuid_cstr, char const * symfile) -> SBModule > AddModule(SBTarget self, SBModuleSpec module_spec) -> SBModule >=20 > The minimum you need to symbolicate a frame is uuid, LoadAddress, and P= C. >=20 > [1] http://lldb.llvm.org/use/map.html > [2] http://lldb.llvm.org/use/symbols.html 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 wo= rk quite fine too. But I am already happy with XCODE5 here, and making it e= ven better will only help myself, but not other people with e.g. Linux or p= eople that want me to use the same compiler with them. Best regards, Vitaly > 21 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0=B2 20:13, Andrew Fis= h =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >=20 >=20 >=20 >> 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 scr= ipts to work with LLDB[1] and was able to debug OVMF built with CLANGPDB. W= hile it is still quite dirty, at the very least it works. >>=20 >> Unfortunately the experience was close to terrible. I may certainly do = something wrong, but it is clear that PDB and LLDB do not support each othe= r well enough. After spending several hours on playing with the tools my co= nclusion is that LLDB is simply not suited for UEFI PDB debugging, and we r= eally want DWARF as there is no other opensource debugger that supports PD= B 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 typ= es. This way EFI_STATUS and EFI_TPL become unsigned long long, CHAR8 become= s char, and CHAR16 becomes unsigned short. It does not look like LLDB has t= he original types anywhere at all, and it also does not have them registere= d. >>=20 >> frame #0: 0x000000007fe242aa DxeCore.dll`CoreAllocatePoolPagesI(Poo= lType=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, Granul= arity, 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 w= e 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, but= they either seem to not relocate or conflict with the other names: >>=20 >> (lldb) p gST >> error: Couldn't materialize: couldn't get the value of variable ::gST: = read memory from 0x6e18 failed >> error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression >> (lldb) p &gST >> error: Couldn't materialize: couldn't get the value of variable ::gST: = read memory from 0x6e18 failed >> error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression >>=20 >=20 > That is strange as globals usually work best? The common issue I've seen= is getting the slide wrong. The EFI modules are linked at a value near zer= o and relocated into memory, so the slide represents that adjustment. >=20 > You can use `image dump sections` and ` image dump symtab` to see lldb's= view of symbols. More info here [1]. >=20 >> 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 use= s Python 3 generally crashes more often than MacPorts LLDB 9.0. Surprisingl= y structures work more or less fine. >>=20 >=20 > You can tell lldb to use the older Python like this (from the Terminal.a= pp): > $ defaults write com.apple.dt.lldb DefaultPythonVersion 2 >=20 >> 4. Ctrl+C does not produce a valid backtrace. When I break with a break= point, I see a proper stacktrace with more than one entry, with function pr= ototypes and values. When I break with Ctrl+C I only see some weird backtra= ce 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 funct= ional TUI, but it is hard to remember all the trials. >>=20 >=20 > For the macOS API clang emits frame pointers, so you can walk the stack = without symbols. You could try adding the compiler flag to emit the frame p= ointers. >=20 >=20 >> [1] https://github.com/acidanthera/OpenCorePkg/blob/master/Debug/Script= s/lldb_uefi.py >>=20 >=20 > On macOS the Mach-O and dSYM have a UUID (dwarfdump -u) that is indexed = by Spotlight (mdfind "com_apple_xcode_dsym_uuids =3D=3D *") [2] > This should be the UUID in the debug directory entry and you can use tha= t to lookup the symbols like this: >=20 > module =3D target.AddModule (None, None, uuid) > SBError =3D target.SetModuleLoadAddress (module, LoadAddress + TeAdjust) >=20 > Also lldb has built in help for commands, but it is kind of terse since = it is autogenerated from the C++ swig. > (lldb) script help (lldb.target.AddModule) > Help on method AddModule in module lldb: >=20 > AddModule(self, *args) method of lldb.SBTarget instance > AddModule(SBTarget self, SBModule module) -> bool > AddModule(SBTarget self, char const * path, char const * triple, cha= r const * uuid) -> SBModule > AddModule(SBTarget self, char const * path, char const * triple, cha= r const * uuid_cstr, char const * symfile) -> SBModule > AddModule(SBTarget self, SBModuleSpec module_spec) -> SBModule >=20 > The minimum you need to symbolicate a frame is uuid, LoadAddress, and P= C. >=20 > [1] http://lldb.llvm.org/use/map.html > [2] http://lldb.llvm.org/use/symbols.html >=20 > Thanks, >=20 > Andrew Fish >=20 >=20 >> Best wishes, >> Vitaly >>=20 >>> 20 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2020 =D0=B3., =D0=B2 22:14, Andrew F= ish > =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 LLVM= toolchain support[1], also wanted to bring ELF format support with DWARF d= ebugging 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 LLV= M 9.0. >>>>=20 >>>> For macOS and XCODE5 toolchain we use GDB scripts based on Andrei War= kentin=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 CL= ANG38/GCC5 with GDB once again. However, CLANGPDB apparently is using PDB d= ebugging information, which I believe is not handled with GDB. >>>>=20 >>>> Could you please provide the details on the matter and let us know ab= out the recommended route? >>>> =E2=80=94 Is dropping CLANGELF just a temporary measure and it should= be resubmitted again? >>>> =E2=80=94 Should LLDB, which seems to be aware of PDB, be used instea= d 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 Q= EMU you need to set plugin.process.gdb-remote.target-definition-file [1] t= o [2]. >>>=20 >>> [1] lldb -o "settings set plugin.process.gdb-remote.target-definition= -file x86_64_target_definition.py" -o "gdb-remote 9000" >>> [2] https://github.com/llvm-mirror/lldb/blob/master/examples/python/x8= 6_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/Scri= pts/gdb_uefi.py >>>>=20 >>=20 >>=20 --Apple-Mail=_31023E76-662B-42F5-90E8-486884B65E56 Content-Type: multipart/mixed; boundary="Apple-Mail=_1DCC97AF-E04C-48EC-8905-4DB5147C5E0E" --Apple-Mail=_1DCC97AF-E04C-48EC-8905-4DB5147C5E0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Andrew,
Thanks once again, but unfortunately it = is not that simple. Below I answered inline explaining the particular = issues, which mostly seem to be specific to CLANGPDB. LLVM stac= k emits PDB debug files, and even though LLDB does support them to some lev= el, it is unlikely that this will be working well enough soon. We should re= ally stick to more or less native debug formats, ideally those that have pr= oper open specifications, on all platforms, and for Unix that=E2=80=99s DWA= RF.

I am pretty sure LLVM can be taught to emit DWARF debug inform= ation even for PE files. Perhaps we can either make some option or provide = a separate toolchain for this? Another way would be recovering CLANGELF as = originally suggested.

You can teach l= ldb 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 have not yet complet= ed these changes for my scripts for LLDB, only for GDB. However, with CLANG= PDB generated files it is not functional. The reason for this is because LL= DB is unaware of the underlying type, i.e. it does not know what is EFI_STA= TUS or UINT32. I can implement pretty-printing when LLDB knows about a type= def, but it is not possible to do this when the debug information is alread= y gone or not parsed:

(lldb) p Status
(unsigned long long) $1 =3D 0
(lldb) p &Status
(unsigned long long *) $2 =3D 0x0= 00000007fe19ad8
(lldb) p (EFI_STATUS)Status
err= or: use of undeclared identifier 'EFI_STATUS'
Just in case I tried using exactly your code, and ot= her stuff like source level debugging works just fine and symbolication wor= ks fine, so it should be some bug with PDB in particular.
= =
That is strange as globals usually work best? The common issue I= 've seen is getting the slide wrong. The EFI modules are linked at a value = near zero and relocated into memory, so the slide represents that adjustmen= t. 

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

Yes, this one is a bit complicated, once again due to PDB most likel= y. It knows about global symbols, but does not list them in symtab:

(lldb) image dump symtab
Du= mping symbol table for 91 modules.
Symtab, file =3D GdbSyms/B= in/X64_CLANGPDB/GdbSyms.dll, num_symbols =3D 0
Symtab, file = =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_CLANGPDB/X64/M= deModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll, num_symbols =3D 0
Symtab, file =3D /Users/user/Documents/UefiWorkspace/Build/OvmfX64/N= OOPT_CLANGPDB/X64/MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe/DEBUG/= DevicePathDxe.dll, num_symbols =3D 0
=E2=80=A6

The slides are correct, but there are two nuances that co= llide with it.

1. There are multiple in= stances of the globals with the same name (e.g. gBS), but for some reason L= LDB always tries to print the globals from the first module. This happens e= ven when I am source-level debugging, and I see a gBS symbol from another m= odule (e.g. DxeCore) used right at the same line. With GDB the closest symb= ol is used, but with LLDB it is always coming from the first module. I trie= d checking expr help to find whether I can pass it a module explicitly, but= also failed.

2.  To be able to ge= t EFI types to locate the EFI_SYSTEM_TABLE_POINTER I add a dummy GdbSyms im= age, 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 it failed for me.

(lldb)&nb= sp;image dump sections
Dumping sections for 91 modules.
Sections for 'GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll' (x86_64):
  SectID     Type     =         Load Address       &nb= sp;                    &n= bsp;Perm File Off.  File Size  Flags     = ; Section Name
  ---------- ---------------- -= --------------------------------------  ---- ---------- ---------= - ---------- ----------------------------
  0xfffff= fffffffffff container        [0x0000000000000000-0= x0000000000006ec0)* ---  0x00000000 0x00000000 0x00000000 GdbSyms= .dll.
  0x00000001 code       &= nbsp;     [0x0000000000000220-0x0000000000005bd6)* --- =  0x00000220 0x000059c0 0x60000020 GdbSyms.dll...text
&nb= sp; 0x00000002 data            &nbs= p;[0x0000000000005be0-0x0000000000006d79)* ---  0x00005be0 0x0000= 11a0 0x40000040 GdbSyms.dll...rdata
  0x00000003 da= ta             [0x0000000000006d80-= 0x0000000000006e30)* ---  0x00006d80 0x00000060 0xc0000040 GdbSym= s.dll...data
  0x00000004 regular    &nbs= p;     [0x0000000000006e40-0x0000000000006ea4)* --- &nb= sp;0x00006de0 0x00000080 0x42000040 GdbSyms.dll...reloc
Secti= ons for '/Users/user/Documents/UefiWorkspace/Build/OvmfX64/NOOPT_CLANGPDB/X= 64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll' (x86_64):
  SectID     Type       =       Load Address         &nb= sp;                   Per= m File Off.  File Size  Flags      = Section Name
  ---------- ---------------- --------= -------------------------------  ---- ---------- ---------- -----= ----- ----------------------------
  0xffffffffffff= ffff container        [0x0000000000000000-0x000000= 00000523a0)* ---  0x00000000 0x00000000 0x00000000 DxeCore.dll.  0x00000001 code         &= nbsp;   [0x000000007fe1b220-0x000000007fe61e34)  ---&nb= sp; 0x00000220 0x00046c20 0x60000020 DxeCore.dll...text
=   0x00000002 data            &= nbsp;[0x000000007fe61e40-0x000000007fe68065)  ---  0x00= 046e40 0x00006240 0x40000040 DxeCore.dll...rdata
  = 0x00000003 data             [0x0000= 00007fe68080-0x000000007fe6d160)  ---  0x0004d080 0x000= 018a0 0xc0000040 DxeCore.dll...data
  0x00000004 re= gular          [0x000000007fe6d160-0x00000000= 7fe6d398)  ---  0x0004e920 0x00000240 0x42000040 DxeCor= e.dll...reloc
Sections for '/Users/user/Documents/UefiWorkspa= ce/Build/OvmfX64/NOOPT_CLANGPDB/X64/MdeModulePkg/Universal/DevicePathDxe/De= vicePathDxe/DEBUG/DevicePathDxe.dll' (x86_64):
  Se= ctID     Type           &= nbsp; Load Address             &nbs= p;               Perm File Off.&nbs= p; File Size  Flags      Section Name  ---------- ---------------- -----------------------= ----------------  ---- ---------- ---------- ---------- ---------= -------------------
  0xffffffffffffffff container&= nbsp;       [0x0000000000000000-0x0000000000014420)* --= -  0x00000000 0x00000000 0x00000000 DevicePathDxe.dll.
  0x00000001 code           =   [0x000000007f986220-0x000000007f996cc6)  --- &nb= sp;0x00000220 0x00010ac0 0x60000020 DevicePathDxe.dll...text
=   0x00000002 data            &= nbsp;[0x000000007f996ce0-0x000000007f999b04)  ---  0x00= 010ce0 0x00002e40 0x40000040 DevicePathDxe.dll...rdata
 =  0x00000003 data             [= 0x000000007f999b20-0x000000007f99a1a2)  ---  0x00013b20= 0x00000660 0xc0000040 DevicePathDxe.dll...data
  0= x00000004 regular          [0x000000007f99a1c= 0-0x000000007f99a404)  ---  0x00014180 0x00000260 0x420= 00040 DevicePathDxe.dll=E2=80=A6reloc
=E2=80=A6
So, all in all, unique global variables work, but th= ere is no way to access duplicating variables. They either resolve to GdbSy= ms or just cause a crash:

(lldb) p= mDebugInfoTableHeader
(EFI_DEBUG_IMAGE_INFO_TABLE_HEADER) $0= =3D {
  UpdateStatus =3D 2
 &nb= sp;TableSize =3D 92
  EfiDebugImageInfoTable =3D 0x= 000000007f814018
}
(lldb) p gBS
error: Couldn't materialize: couldn't get the value of variable ::gB= S: read memory from 0x6df8 failed
error: errored out in DoExe= cute, couldn't PrepareToExecuteJITExpression
(lldb) p gE= fiGlobalVariableGuid
0  libLLVM.dylib    =         0x000000010e52ee68 llvm::sys::PrintStackTr= ace(llvm::raw_ostream&) + 40
1  libLLVM.dylib&n= bsp;           0x000000010e52f262 SignalHandl= er(int) + 188
2  libsystem_platform.dylib 0x00007ff= f6ca5642d _sigtramp + 29
...

<= div>
You can tell lldb = to use the older Python like this (from the Terminal.app):
$ defaults write com.apple.dt.lldb DefaultPythonVersion 2
=

Thanks, that helped quite a bit, but= for some reason Xcode version still crashes more for me. I attached a coup= le of stack traces if you feel like having a look, but once again it seems = that it is all about the PDB plugin.

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

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

(ll= db) b CoreLocateHandleBuffer
Breakpoint 2: where =3D Dxe= Core.dll`CoreLocateHandleBuffer + 31 at Locate.c:649, address =3D 0x0000000= 07fe36e4f
(lldb) c
Process 1 resuming
Process 1 stopped
* thread #1, stop reason =3D = ;breakpoint 2.1
    frame #0: 0x000000007= fe36e4f DxeCore.dll`CoreLocateHandleBuffer(SearchType=3DByProtocol, Pr= otocol=3D0x000000007f978160, SearchKey=3D0x0000000000000000, NumberHandles= =3D0x000000007fe19fd8, Buffer=3D0x000000007fe19fc0) at Locate.c:= 649
   646    EFI_STATUS      &n= bsp;   Status;
   647    UINTN &= nbsp;             BufferSize;
   648 
-> 649    if (NumberHandles = =3D=3D NULL) {
   650      return EF= I_INVALID_PARAMETER;
   651    }
=    652 
(lldb) bt
* thread #1, stop r= eason =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
    frame #1: 0x000000007fe368= 16 DxeCore.dll`CoreLocateDevicePath(Protocol=3D0x000000007f978160, Dev= icePath=3D0x000000007fe1a060, Device=3D0x000000007fe1a068) at Locate.c= :466
    frame #2: 0x000000007f97479a&nbs= p;SecurityStubDxe.dll

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

(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&nbs= p;MnpDxe.dll`CopyMem(DestinationBuffer=3D0x000000007fe19b50, SourceBuffer= =3D0x000000007e2aa470, Length=3D656) at CopyMemWrapper.c:47
   44     IN UINTN       = ;Length
   45     )
  &= nbsp;46   {
-> 47     if (Length =3D=3D = 0) {
   48       return Destinat= ionBuffer;
   49     }
 = ;  50     ASSERT ((Length - 1) <=3D (MAX_ADDRESS - (U= INTN)DestinationBuffer));
(lldb) bt
* thre= ad #1, stop reason =3D breakpoint 2.53 3.53
  = * frame #0: 0x000000007e5c13b3 MnpDxe.dll`CopyMem(DestinationBuff= er=3D0x000000007fe19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) a= t CopyMemWrapper.c:47
(lldb) finish
e= rror: Could not create return address breakpoint.
(lldb) = ;n
Process 1 stopped
* thread #1, stop reason = =3D step over
    frame #0: 0x00000= 0007e5c13ce MnpDxe.dll`CopyMem(DestinationBuffer=3D0x000000007fe19b50,= SourceBuffer=3D0x000000007e2aa470, Length=3D656) at CopyMemWrapper.c:= 50
   47     if (Length =3D=3D 0= ) {
   48       return Destinati= onBuffer;
   49     }
-> = 50     ASSERT ((Length - 1) <=3D (MAX_ADDRESS - (UINTN)Des= tinationBuffer));
   51     ASSERT ((Lengt= h - 1) <=3D (MAX_ADDRESS - (UINTN)SourceBuffer));
&nb= sp;  52  
   53     if (Destinat= ionBuffer =3D=3D SourceBuffer) {
(lldb)  
...
Process 1 stopped
* thread #1, stop = reason =3D step over
    frame #0: 0= x000000007e5c14b4 MnpDxe.dll`CopyMem(DestinationBuffer=3D0x000000007fe= 19b50, SourceBuffer=3D0x000000007e2aa470, Length=3D656) at CopyMemWrap= per.c:57
   54       return Dest= inationBuffer;
   55     }
&= nbsp;  56     return InternalMemCopyMem (DestinationBuff= er, SourceBuffer, Length);
-> 57   }
(lldb)&n= bsp; 
Process 1 stopped
* thread #1, stop = reason =3D step over
    frame #0: 0= x000000007e5c726e MnpDxe.dll
->  0x7e5c726e= : mov    rax, qword ptr [rsp + 0x60]
  &n= bsp; 0x7e5c7273: cmp    byte ptr [rax + 0x68], 0x0
    0x7e5c7277: jne    0x7e5c7291    0x7e5c727d: movabs rax, -0x7fffffffffffffed=
(lldb) bt
* thread #1, stop reason =3D&nb= sp;step over
  * frame #0: 0x0= 00000007e5c726e MnpDxe.dll 

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

(lldb)=  c
Process 1 resuming
Process 1 stopped* thread #1, stop reason =3D signal SIGINT
&= nbsp;   frame #0: 0x000000007fe4d72e DxeCore.dll
->  0x7fe4d72e: cmp    al, 0x0
    0x7fe4d730: je     0x7fe4d765=
    0x7fe4d736: mov    rcx, qw= ord ptr [rsp + 0x20]
    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_uuids =3D=3D *") [2]
This shoul= d be the UUID in the debug directory entry and you can use that to lookup t= he symbols like this:

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

Also lldb has built= in help for commands, but it is kind of terse since it is autogenerated fr= om the C++ swig. 
(lldb) script help (lldb.targ= et.AddModule)
Help on = method AddModule in module lldb:

AddModule(self, *args) method of lldb.SBTarget insta= nce
    AddM= odule(SBTarget self, SBModule module) -> bool
    AddModule(SBTarget self, char cons= t * path, char const * triple, char const * uuid) -> SBModule
    AddModule(SBTarget= self, char const * path, char const * triple, char const * uuid_cstr, char= const * symfile) -> SBModule
    AddModule(SBTarget self, SBModuleSpec module_spec)= -> SBModule

The minimum  you need to symbolicate a frame is uuid, LoadAddre= ss, and PC. 

[1] http://lldb.llvm.org/use/map.html
[2] = http://lldb.ll= vm.org/use/symbols.html

Tha= nks 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 ver= y likely that when I get to complete LLDB support for XCODE5 it will work q= uite fine too. But I am already happy with XCODE5 here, and making it even = better will only help myself, but not other people with e.g. Linux or peopl= e that want me to use the same compiler with them.

Best regards,
Vitaly

<= div>

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



On Mar 21, 2020, at 3:28 A= M, Vitaly Cheptsov <che= ptsov@ispras.ru> wrote:

Hello,
Andrey, than= ks for the hint, it was very helpful. I rewrote the GDB scripts to work wit= h LLDB[1] and was able to debug OVMF built with CLANGPDB. While it is still= quite dirty, at the very least it works.

Un= fortunately the experience was close to terrible. I may certainly do someth= ing 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 conclusi= on 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

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

1.= All integer alias typedefs are discarded in favour of underlying types. Th= is way EFI_STATUS and EFI_TPL become unsigned long long, CHAR8 becomes char= , and CHAR16 becomes unsigned short. It does not look like LLDB has the ori= ginal types anywhere at all, and it also does not have them registered.

    frame #0: 0x00000000= 7fe242aa DxeCore.dll`CoreAllocatePoolPagesI(PoolType=3DEfiBootServices= Data, NoPages=3D1, Granularity=3D4096, NeedGuard=3D'\0') at Pool.c:322=
   319      return NULL;
   320    }
   321 
-> 322    Buffer =3D CoreAllocatePoolPages (PoolType, NoPag= es, Granularity, NeedGuard);
   323    CoreRe= leaseMemoryLock ();
   324 
   = ;325    if (Buffer !=3D NULL) {
(lldb) p Stat= us
(unsigned long long) $3 =3D 0

Structures work= more or less fine, but for simpler types like strings we are out of even p= otential pretty-printing.


Vitaly= ,

You can teach lldb about types. There is s= ome example code here: https://github.com/tianoc= ore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py

2. Global variables are not accessible. I am not sur= e what happens, but they either seem to not relocate or conflict with the o= ther names:

(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, c= ouldn't PrepareToExecuteJITExpression
(lldb) p &gST<= br class=3D"">error: Couldn't materialize: couldn't get the value of variab= le ::gST: read memory from 0x6e18 failed
error: errored out i= n DoExecute, couldn't PrepareToExecuteJITExpression


That is strange as globals usually work best? The common issue= I've seen is getting the slide wrong. The EFI modules are linked at a valu= e near zero and relocated into memory, so the slide represents that adjustm= ent. 

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

3. Quite a num= ber of crashes.

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

b I<TA= B>

So will do printing of a GUID, e.g.&nb= sp;p gE= fiGlobalVariableGuid.
<= span class=3D"" style=3D"font-family: "Helvetica Neue";">
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 = (from the Terminal.app):
$&nbs= p;defaults write com.apple.dt.lldb DefaultPythonVersion 2

4. Ctrl+C does not produce a valid backtrace. When = I break with a breakpoint, I see a proper stacktrace with more than one ent= ry, with function prototypes and values. When I break with Ctrl+C I only se= e some weird backtrace with most of the entries missing regardless of frame= position:

(lldb) bt
* thread #1, stop reason =3D&= nbsp;signal SIGTRAP
  * frame #0: 0x000000007f= e4c5f3 DxeCore.dll

Probably more and all the unintuitive stuff like the lack of more function= al 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 compiler flag = to emit the frame pointers. 


[1] https://github.com/ac= idanthera/OpenCorePkg/blob/master/Debug/Scripts/lldb_uefi.py

=

On macOS the Mach-O and dSYM have a UUID (dwarfdu= mp -u) that is indexed by Spotlight (mdfind "com_apple_xcode_dsym_uuids =3D= = =3D *") [2]
This should be th= e UUID in the debug directory entry and you can use that to lookup the symb= ols like this:

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

Also lldb has built in help for commands, but it is kind o= f terse since it is autogenerated from the C++ swig. 
= (lldb) <= /span>script help (lldb.target.AddModule)
Help on method AddModule in module lldb:

AddModule(self, *ar= gs) method of lldb.SBTarget instance
    AddModule(SBTarget self, SBModule module) ->= ; bool
   = AddModule(SBTarget self, char const * path, char const * triple, char cons= t * uuid) -> SBModule
    AddModule(SBTarget self, char const * path, char const * t= riple, char const * uuid_cstr, char const * symfile) -> SBModule<= /div>
    AddModule(SBTar= get self, SBModuleSpec module_spec) -> SBModule

The minimum  you need to = symbolicate a frame is uuid, LoadAddress, and PC. 
<= div style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; l= etter-spacing: normal; text-align: start; text-indent: 0px; text-transform:= none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0= px; text-decoration: none;" class=3D"">
[1] http://lldb.ll= vm.org/use/map.html
[2]&nb= sp;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 <afish@apple.com> =D0=BD=D0= =B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):



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

Hello,

We no= ticed that the original bugzilla, which intended to add new LLVM toolchain = support[1], also wanted to bring ELF format support with DWARF debugging in= formation. For s= ome reason this did not make its way into EDK II, and we are currently wond= ering, how can one debug binaries built with LLVM 9.0.

For macOS and XCODE5 toolchain we use GDB scripts based on <= /span>Andrei Warkentin=E2=80=99s work, which allow us to i= ntegrate with QEMU and VMware[2]. It is likely that they should work with l= ittle to no work on Linux with CLANG38/GCC5 with GDB once again. However, C= LANGPDB apparently is using PDB debugging information, which I believe is n= ot handled with GDB.

Could you please provide the details on the matter and let us kn= ow about the recommended route?
=E2=80=94 Is dropping = CLANGELF just a temporary measure and it should be resubmitted again?
=
=E2=80=94 Should LLDB, which seems to be aware of PDB, be used instead of G= DB, when building with CLANGPDB? If so, did anybody try that?
<= div class=3D"">

Vi= taly,

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

[1]  lldb -o "settings set plugin.process.gdb-remote.target= -definition-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


And= rew Fish

= Thanks!
<= div class=3D"">
Best regards,
Vitaly

[2] https://gith= ub.com/acidanthera/OpenCorePkg/blob/master/Debug/Scripts/gdb_uefi.py


<= /div>
--Apple-Mail=_1DCC97AF-E04C-48EC-8905-4DB5147C5E0E Content-Disposition: attachment; filename=crashes.txt Content-Type: text/plain; x-unix-mode=0644; name="crashes.txt" Content-Transfer-Encoding: quoted-printable E.g. this is what happens when I type =C2=ABb In=C2=BB. I cannot repro= duce it with stock LLDB. (lldb) b In0 lldb 0x0000000102638705 llvm::sys::PrintS= tackTrace(llvm::raw_ostream&) + 37 1 lldb 0x0000000102637d77 llvm::sys::RunSignalHandlers= () + 39 2 lldb 0x0000000102638d58 SignalHandler(int) + 264 3 libsystem_platform.dylib 0x00007fff6ca5642d _sigtramp + 29 4 libsystem_platform.dylib 000000000000000000 _sigtramp + 2472188912 5 LLDB 0x0000000102dbf200 llvm::BinaryStreamReader::Bi= naryStreamReader(llvm::BinaryStream&) + 32 6 LLDB 0x00000001030ba527 llvm::pdb::ModuleDebugStream= Ref::reload() + 39 7 LLDB 0x0000000102d589ff lldb_private::npdb::CompileU= nitIndex::GetOrCreateCompiland(unsigned short) + 319 8 LLDB 0x0000000102d72077 lldb_private::npdb::SymbolFi= leNativePDB::ParseCompileUnitAtIndex(unsigned int) + 119 9 LLDB 0x00000001029cf71d lldb_private::SymbolVendor::= GetCompileUnitAtIndex(unsigned long) + 221 10 LLDB 0x000000010288659a lldb_private::Module::GetCom= pileUnitAtIndex(unsigned long) + 106 11 LLDB 0x000000010289fb10 lldb_private::SearchFilter::= DoCUIteration(std::__1::shared_ptr const&, lldb_priva= te::SymbolContext const&, lldb_private::Searcher&) + 208 12 LLDB 0x000000010289f7b3 lldb_private::SearchFilter::= DoModuleIteration(lldb_private::SymbolContext const&, lldb_private::Searche= r&) + 419 13 LLDB 0x000000010289f5f4 lldb_private::SearchFilter::= Search(lldb_private::Searcher&) + 180 14 LLDB 0x0000000102e5563d lldb_private::CommandComplet= ions::SourceFileCompleter::DoCompletion(lldb_private::SearchFilter*) + 29 15 LLDB 0x0000000102e54c28 lldb_private::CommandComplet= ions::SourceFiles(lldb_private::CommandInterpreter&, lldb_private::Completi= onRequest&, lldb_private::SearchFilter*) + 200 16 LLDB 0x0000000102e555ed lldb_private::CommandComplet= ions::InvokeCommonCompletionCallbacks(lldb_private::CommandInterpreter&, un= signed int, lldb_private::CompletionRequest&, lldb_private::SearchFilter*) = + 93 17 LLDB 0x000000010293b331 lldb_private::CommandObjectR= egexCommand::HandleCompletion(lldb_private::CompletionRequest&) + 33 18 LLDB 0x00000001029310e8 lldb_private::CommandInterpr= eter::HandleCompletionMatches(lldb_private::CompletionRequest&) + 424 19 LLDB 0x000000010293135d lldb_private::CommandInterpr= eter::HandleCompletion(char const*, char const*, char const*, int, int, lld= b_private::StringList&, lldb_private::StringList&) + 349 20 LLDB 0x0000000102871eaa lldb_private::IOHandlerDeleg= ate::IOHandlerComplete(lldb_private::IOHandler&, char const*, char const*, = char const*, int, int, lldb_private::StringList&, lldb_private::StringList&= ) + 90 21 LLDB 0x0000000102872547 lldb_private::IOHandlerEditl= ine::AutoCompleteCallback(char const*, char const*, char const*, int, int, = lldb_private::StringList&, lldb_private::StringList&, void*) + 55 22 LLDB 0x00000001029155fe lldb_private::Editline::TabC= ommand(int) + 110 23 LLDB 0x0000000102917931 lldb_private::Editline::Conf= igureEditor(bool)::$_13::__invoke(editline*, int) + 33 24 libedit.3.dylib 0x00007fff6a3fc7db el_wgets + 484 25 libedit.3.dylib 0x00007fff6a4078bb el_gets + 37 26 LLDB 0x0000000102916df7 lldb_private::Editline::GetL= ine(std::__1::basic_string, std::__1::all= ocator >&, bool&) + 439 27 LLDB 0x00000001028727bc lldb_private::IOHandlerEditl= ine::GetLine(std::__1::basic_string, std:= :__1::allocator >&, bool&) + 60 28 LLDB 0x0000000102872f3e lldb_private::IOHandlerEditl= ine::Run() + 190 29 LLDB 0x000000010285a3cb lldb_private::Debugger::Exec= uteIOHandlers() + 123 30 LLDB 0x000000010293589c lldb_private::CommandInterpr= eter::RunCommandInterpreter(bool, bool, lldb_private::CommandInterpreterRun= Options&) + 156 31 LLDB 0x00000001026deb91 lldb::SBDebugger::RunCommand= Interpreter(bool, bool) + 209 32 lldb 0x0000000102623665 Driver::MainLoop() + 2853 33 lldb 0x00000001026245d2 main + 1634 34 libdyld.dylib 0x00007fff6c85d7fd start + 1 35 libdyld.dylib 0x000000000000000f start + 2474256403 Stack dump: 0. Program arguments: /Applications/Xcode.app/Contents/Developer/usr/bin/l= ldb -o settings set plugin.process.gdb-remote.target-definition-file Script= s/x86_64_target_definition.py -o gdb-remote 8864 -o target modules add -s G= dbSyms/Bin/X64_CLANGPDB/GdbSyms.pdb GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll -o= command script import Scripts/lldb_uefi.py -o command script add -c lldb_u= efi.ReloadUefi reload-uefi -o reload-uefi -o b DebugBreak=20 ./maclldb.tool: line 33: 37553 Segmentation fault: 11 "$LLDB" -o "settings= set plugin.process.gdb-remote.target-definition-file Scripts/x86_64_target= _definition.py" -o "gdb-remote $LLDB_PORT" -o "target modules add -s GdbSym= s/Bin/X64_CLANGPDB/GdbSyms.pdb GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll" -o "co= mmand script import Scripts/lldb_uefi.py" -o "command script add -c lldb_ue= fi.ReloadUefi reload-uefi" -o "reload-uefi" -o "b DebugBreak" This I cannot reproduce with stock GDB either: (lldb) p mDebugInfoTableHeader 0 lldb 0x0000000102e13705 llvm::sys::PrintStackTrace(l= lvm::raw_ostream&) + 37 1 lldb 0x0000000102e12d77 llvm::sys::RunSignalHandlers= () + 39 2 lldb 0x0000000102e13d58 SignalHandler(int) + 264 3 libsystem_platform.dylib 0x00007fff6ca5642d _sigtramp + 29 4 libsystem_platform.dylib 0xaae108ecfd74df7c _sigtramp + 2429516652 5 LLDB 0x000000010359e200 llvm::BinaryStreamReader::Bi= naryStreamReader(llvm::BinaryStream&) + 32 6 LLDB 0x0000000103899527 llvm::pdb::ModuleDebugStream= Ref::reload() + 39 7 LLDB 0x00000001035379ff lldb_private::npdb::CompileU= nitIndex::GetOrCreateCompiland(unsigned short) + 319 8 LLDB 0x0000000103540a77 lldb_private::npdb::PdbAstBu= ilder::ParseAllNamespacesPlusChildrenOf(llvm::Optional) + = 663 9 LLDB 0x00000001035414e2 lldb_private::npdb::PdbAstBu= ilder::ParseDeclsForContext(clang::DeclContext&) + 82 10 LLDB 0x0000000103550fef lldb_private::npdb::SymbolFi= leNativePDB::ParseDeclsForContext(lldb_private::CompilerDeclContext) + 63 11 LLDB 0x000000010315604c lldb_private::ClangASTContex= t::DeclContextFindDeclByName(void*, lldb_private::ConstString, bool) + 668 12 LLDB 0x00000001031627b9 lldb_private::CompilerDeclCo= ntext::FindDeclByName(lldb_private::ConstString, bool) + 57 13 LLDB 0x00000001032f1b76 lldb_private::ClangExpressio= nDeclMap::FindExternalVisibleDecls(lldb_private::NameSearchContext&, std::_= _1::shared_ptr, lldb_private::CompilerDeclContext&, u= nsigned int) + 1014 14 LLDB 0x00000001032f1334 lldb_private::ClangExpressio= nDeclMap::FindExternalVisibleDecls(lldb_private::NameSearchContext&) + 628 15 LLDB 0x00000001032e63b6 lldb_private::ClangASTSource= ::FindExternalVisibleDeclsByName(clang::DeclContext const*, clang::Declarat= ionName) + 1174 16 LLDB 0x000000010635e802 clang::DeclContext::lookup(c= lang::DeclarationName) const + 754 17 LLDB 0x0000000105ff1f66 LookupDirect(clang::Sema&, c= lang::LookupResult&, clang::DeclContext const*) + 86 18 LLDB 0x0000000105fee3e9 clang::Sema::CppLookupName(c= lang::LookupResult&, clang::Scope*) + 3257 19 LLDB 0x0000000105ff1795 clang::Sema::LookupName(clan= g::LookupResult&, clang::Scope*, bool) + 725 20 LLDB 0x0000000105d66a63 clang::Sema::ClassifyName(cl= ang::Scope*, clang::CXXScopeSpec&, clang::IdentifierInfo*&, clang::SourceLo= cation, clang::Token const&, bool, std::__1::unique_ptr >) + 419 21 LLDB 0x0000000105b0ac14 clang::Parser::TryAnnotateNa= me(bool, std::__1::unique_ptr >) + 484 22 LLDB 0x0000000105aeb55a clang::Parser::ParseStatemen= tOrDeclarationAfterAttributes(llvm::SmallVector&, clang:= :Parser::AllowedConstructsKind, clang::SourceLocation*, clang::Parser::Pars= edAttributesWithRange&) + 394 23 LLDB 0x0000000105aeb279 clang::Parser::ParseStatemen= tOrDeclaration(llvm::SmallVector&, clang::Parser::Allowe= dConstructsKind, clang::SourceLocation*) + 201 24 LLDB 0x0000000105af263c clang::Parser::ParseCompound= StatementBody(bool) + 1644 25 LLDB 0x0000000105af3131 clang::Parser::ParseFunction= StatementBody(clang::Decl*, clang::Parser::ParseScope&) + 161 26 LLDB 0x0000000105b09780 clang::Parser::ParseFunction= Definition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo con= st&, clang::Parser::LateParsedAttrList*) + 2608 27 LLDB 0x0000000105a84045 clang::Parser::ParseDeclGrou= p(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*= , clang::Parser::ForRangeInit*) + 1781 28 LLDB 0x0000000105b08a37 clang::Parser::ParseDeclOrFu= nctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::Parsing= DeclSpec&, clang::AccessSpecifier) + 695 29 LLDB 0x0000000105b084e3 clang::Parser::ParseDeclarat= ionOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::P= arsingDeclSpec*, clang::AccessSpecifier) + 339 30 LLDB 0x0000000105b06c57 clang::Parser::ParseExternal= Declaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSp= ec*) + 2535 31 LLDB 0x0000000105b05d97 clang::Parser::ParseTopLevel= Decl(clang::OpaquePtr&) + 679 32 LLDB 0x0000000105a71855 clang::ParseAST(clang::Sema&= , bool, bool) + 453 33 LLDB 0x0000000105a71672 clang::ParseAST(clang::Prepr= ocessor&, clang::ASTConsumer*, clang::ASTContext&, bool, clang::Translation= UnitKind, clang::CodeCompleteConsumer*, bool) + 194 34 LLDB 0x00000001033094a1 lldb_private::ClangExpressio= nParser::ParseInternal(lldb_private::DiagnosticManager&, clang::CodeComplet= eConsumer*, unsigned int, unsigned int) + 1729 35 LLDB 0x0000000103315793 lldb_private::ClangUserExpre= ssion::Parse(lldb_private::DiagnosticManager&, lldb_private::ExecutionConte= xt&, lldb_private::ExecutionPolicy, bool, bool) + 499 36 LLDB 0x00000001030deaf5 lldb_private::UserExpression= ::Evaluate(lldb_private::ExecutionContext&, lldb_private::EvaluateExpressio= nOptions const&, llvm::StringRef, llvm::StringRef, lldb_private::SharingPtr= &, lldb_private::Status&, unsigned int, std::__1= ::basic_string, std::__1::allocator= >*, std::__1::shared_ptr*) + 1701 37 LLDB 0x0000000103241542 lldb_private::Target::Evalua= teExpression(llvm::StringRef, lldb_private::ExecutionContextScope*, lldb_pr= ivate::SharingPtr&, lldb_private::EvaluateExpres= sionOptions const&, std::__1::basic_string, std::__1::allocator >*) + 418 38 LLDB 0x000000010364dd06 lldb_private::CommandObjectE= xpression::EvaluateExpression(llvm::StringRef, lldb_private::Stream*, lldb_= private::Stream*, lldb_private::CommandReturnObject*) + 566 39 LLDB 0x000000010364ec56 lldb_private::CommandObjectE= xpression::DoExecute(llvm::StringRef, lldb_private::CommandReturnObject&) += 1270 40 LLDB 0x000000010311877b lldb_private::CommandObjectR= aw::Execute(char const*, lldb_private::CommandReturnObject&) + 427 41 LLDB 0x000000010310fd25 lldb_private::CommandInterpr= eter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::Comm= andReturnObject&, lldb_private::ExecutionContext*, bool, bool) + 2805 42 LLDB 0x0000000103113d61 lldb_private::CommandInterpr= eter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__1::basic_stri= ng, std::__1::allocator >&) + 657 43 LLDB 0x0000000103051f9d lldb_private::IOHandlerEditl= ine::Run() + 285 44 LLDB 0x00000001030393cb lldb_private::Debugger::Exec= uteIOHandlers() + 123 45 LLDB 0x000000010311489c lldb_private::CommandInterpr= eter::RunCommandInterpreter(bool, bool, lldb_private::CommandInterpreterRun= Options&) + 156 46 LLDB 0x0000000102ebdb91 lldb::SBDebugger::RunCommand= Interpreter(bool, bool) + 209 47 lldb 0x0000000102dfe665 Driver::MainLoop() + 2853 48 lldb 0x0000000102dff5d2 main + 1634 49 libdyld.dylib 0x00007fff6c85d7fd start + 1 50 libdyld.dylib 0x000000000000000f start + 2474256403 Stack dump: 0. Program arguments: /Applications/Xcode.app/Contents/Developer/usr/bin/l= ldb -o settings set plugin.process.gdb-remote.target-definition-file Script= s/x86_64_target_definition.py -o gdb-remote 8864 -o target modules add -s G= dbSyms/Bin/X64_CLANGPDB/GdbSyms.pdb GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll -o= command script import Scripts/lldb_uefi.py -o command script add -c lldb_u= efi.ReloadUefi reload-uefi -o reload-uefi -o b DebugBreak=20 ./maclldb.tool: line 33: 37722 Segmentation fault: 11 "$LLDB" -o "settings= set plugin.process.gdb-remote.target-definition-file Scripts/x86_64_target= _definition.py" -o "gdb-remote $LLDB_PORT" -o "target modules add -s GdbSym= s/Bin/X64_CLANGPDB/GdbSyms.pdb GdbSyms/Bin/X64_CLANGPDB/GdbSyms.dll" -o "co= mmand script import Scripts/lldb_uefi.py" -o "command script add -c lldb_ue= fi.ReloadUefi reload-uefi" -o "reload-uefi" -o "b DebugBreak" --Apple-Mail=_1DCC97AF-E04C-48EC-8905-4DB5147C5E0E-- --Apple-Mail=_31023E76-662B-42F5-90E8-486884B65E56-- --Apple-Mail=_70470479-C16E-41AA-96F6-03AE5C2D084B 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----- iQIzBAEBCgAdFiEEsLABAI5Y5VbvBdmpL8K2O86Eyz4FAl52XqIACgkQL8K2O86E yz7xVBAAiK4LGXTY1vdzKStDTSQLa5f5zkQilZdd8xqK1ym3cIZ2vEuq5EPqfzjo isXDj7vsaMasn2+exWiTMJUA0TP/pzIvT0l8AP0at5fFY00gMjSMiD4BiW8hJc9c HZqcnI0Wf1dMs/e7mnTTiCvrxk11pJPTAYePpVMt+ek/8st+Rko6R4BajSrA9tKf 2xnXXZRdKbEe97FQa2zfKKsVbo88r+RpOpvMlqL/KQICE8XVlWUqzACc/bUwrAAV pkS+gaUtRz1W+8h/TiaqRAfOWNuDgKac/1KJfX27ahKiZm9CJJoA6DaqlrQC172H MCaz/y6bdhrlCERcSYFlHJj4Za9zMFKPMO6ExtBgtmBpAA82tG0bi0iPCAvr58gw 3hr8e5OgpTKGyVdgOld3htpNr1jhAldakQx9s/sWmH28T9DFHm0CqdI7i8Hhqk9N 6ahmEMIiFpxh01k9Sg/rkXFgd75y4Ss/UFwZAOZpgYhnhFg+2MK79Y3UfdBvgBpV bL0iTwrVj31TNUNG/oezqP9bE2Egb25LYf12C3DIC7qdlhTaIIKhQlsp0rkyFwKe ZMz1rIfxTji5RT68AFyfWs3/abASmwcLe1ldDOTsV76l1Ii2iel+RskAjQICnwxQ FHWR3M2W72li6z4AOrkWB6nJosiYLTduNmxG54LRBN8pbCD0CME= =0ha9 -----END PGP SIGNATURE----- --Apple-Mail=_70470479-C16E-41AA-96F6-03AE5C2D084B--