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 <af...@apple.com> написал(а):
>
>
>
>> On Mar 20, 2020, at 8:13 AM, Vitaly Cheptsov <chept...@ispras.ru
>> <mailto:chept...@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/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
signature.asc
Description: Message signed with OpenPGP
