[edk2-devel] CLANGPDB binary debugging

Sat Mar 21 10:28:57 UTC 2020

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.

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

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.

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.

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

Best wishes,
Vitaly

> 20 марта 2020 г., в 22:14, Andrew Fish <afish at apple.com> написал(а):
> 
> 
> 
>> On Mar 20, 2020, at 8:13 AM, Vitaly Cheptsov <cheptsov at ispras.ru <mailto:cheptsov at 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>
>> 
>> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#56065): https://edk2.groups.io/g/devel/message/56065
Mute This Topic: https://groups.io/mt/72100961/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20200321/28b0cc3a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20200321/28b0cc3a/attachment.sig>