> On Mar 21, 2020, at 3:28 AM, Vitaly Cheptsov <chept...@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 <af...@apple.com
>> <mailto: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 (#56071): https://edk2.groups.io/g/devel/message/56071
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]
-=-=-=-=-=-=-=-=-=-=-=-
