Re: [edk2-devel] CLANGPDB binary debugging

["Andrew Fish" <afish@apple.com>]

[-- Attachment #1: Type: text/plain, Size: 7462 bytes --]



> On Mar 21, 2020, at 3:28 AM, Vitaly Cheptsov <cheptsov@ispras.ru> wrote:
> 
> Hello,
> 
> Andrey, thanks for the hint, it was very helpful. I rewrote the GDB scripts to work with LLDB[1] and was able to debug OVMF built with CLANGPDB. While it is still quite dirty, at the very least it works.
> 
> Unfortunately the experience was close to terrible. I may 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 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. This way EFI_STATUS and EFI_TPL become unsigned long long, CHAR8 becomes char, and CHAR16 becomes unsigned short. It does not look like LLDB has the original types anywhere at all, and it also does not have them registered.
> 
>     frame #0: 0x000000007fe242aa DxeCore.dll`CoreAllocatePoolPagesI(PoolType=EfiBootServicesData, NoPages=1, Granularity=4096, NeedGuard='\0') at Pool.c:322
>    319 	    return NULL;
>    320 	  }
>    321 	
> -> 322 	  Buffer = CoreAllocatePoolPages (PoolType, NoPages, Granularity, NeedGuard);
>    323 	  CoreReleaseMemoryLock ();
>    324 	
>    325 	  if (Buffer != NULL) {
> (lldb) p Status
> (unsigned long long) $3 = 0
> 
> Structures work more or less fine, but for simpler types like strings we are out of even potential pretty-printing.
> 

Vitaly,

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:
> 
> (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
> 

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 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 crashes.
> 
> In most cases autocompletion by tab press causes a crash. E.g.
> 
> b I<TAB>
> 
> So will do printing of a GUID, e.g. p gEfiGlobalVariableGuid.
> 
> This may have to do 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):
$ 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 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 reason = signal SIGTRAP
>   * frame #0: 0x000000007fe4c5f3 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 compiler flag to emit the frame pointers. 


> [1] https://github.com/acidanthera/OpenCorePkg/blob/master/Debug/Scripts/lldb_uefi.py <https://github.com/acidanthera/OpenCorePkg/blob/master/Debug/Scripts/lldb_uefi.py>
> 

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

module = target.AddModule (None, None, uuid)
SBError = target.SetModuleLoadAddress (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)
Help on method AddModule in module lldb:

AddModule(self, *args) method of lldb.SBTarget instance
    AddModule(SBTarget self, SBModule module) -> bool
    AddModule(SBTarget self, char const * 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, 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 марта 2020 г., в 22:14, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> написал(а):
>> 
>> 
>> 
>>> On Mar 20, 2020, at 8:13 AM, Vitaly Cheptsov <cheptsov@ispras.ru <mailto:cheptsov@ispras.ru>> wrote:
>>> 
>>> Hello,
>>> 
>>> We noticed that the original bugzilla, which intended to add new LLVM 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 LLVM 9.0.
>>> 
>>> For macOS and XCODE5 toolchain we use GDB scripts based on Andrei Warkentin’s 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.
>>> 
>>> Could you please provide the details on the matter and let us know about the recommended route?
>>> — Is dropping CLANGELF just a temporary measure and it should be resubmitted again?
>>> — Should LLDB, which seems to be aware of PDB, be used instead of GDB, when building with CLANGPDB? If so, did anybody try that?
>>> 
>> 
>> Vitaly,
>> 
>> 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]. 
>> 
>> [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 <https://github.com/llvm-mirror/lldb/blob/master/examples/python/x86_64_target_definition.py>
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> Thanks!
>>> 
>>> Best regards,
>>> Vitaly
>>> 
>>> [1] https://bugzilla.tianocore.org/show_bug.cgi?id=1603 <https://bugzilla.tianocore.org/show_bug.cgi?id=1603>
>>> [2] https://github.com/acidanthera/OpenCorePkg/blob/master/Debug/Scripts/gdb_uefi.py <https://github.com/acidanthera/OpenCorePkg/blob/master/Debug/Scripts/gdb_uefi.py>
>>> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 32797 bytes --]