Re: [edk2-devel] Help with debugging

["Ethin Probst" <harlydavidsen@gmail.com>]

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?

On 6/11/21, Andrew Fish <afish@apple.com> wrote:
>
>
>> On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@gmail.com>
>> wrote:
>>
>> Hey all,
>>
>> So Leif and I have discussed this at length but I thought I'd reach
>> out to all of you for more help.
>>
>> I'm having a lot of trouble debugging my UEFI app. Here's how I do
>> things:
>>
>> - I load the app using uefi-run
>> (https://github.com/Richard-W/uefi-run) like this (from the main EDK
>> II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
>> Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
>> qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
>> -debugcon file:../debug.log -global isa-debugcon.iobase=0x402
>> -nographic
>> Or:
>> uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
>> Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
>> qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
>> -debugcon stdio -global isa-debugcon.iobase=0x402
>> - I connect to the remote GDB stub (localhost:1234) and wait until
>> OVMF gives me the image base. Then I use:
>> add-symbol-file UsbAudio.debug <image base>
>> Here's where everything breaks down. One of two things happens at this
>> point:
>> 1. Either I get the wrong debug information (I get source code but the
>> image isn't loaded anymore), and resetting the system and placing a
>> breakpoint (either software or hardware) has no effect; or
>> 2. If I use CpuBreakpoint(), the firmware gives me the registers and
>> the image base and entry point addresses, and then appears to just sit
>> there waiting for something. Once I load the symbols using the image
>> base it gives me, I can't actually do anything in the debugger; I
>> can't list code because I get "1 in <artificial>", I can't jump into
>> my code without triggering a general protection exception or not
>> actually causing anything to happen... You get the idea.
>>
>> So I'm really, really confused on what's going wrong. Do you guys have
>> any advice?
>
> Ethin,
>
> Caveat emptor as I use lldb for my daily driver debugger so I might be a
> little off on gdb specifics…. Also my terminology may be lldb centric.
>
> Easy one 1st. When you run on top of a debugger using CpuBreakpoint() works
> great as the debugger hides its self from you. On x86 CpuBreakpoint() is an
> INT 3h instruction (0xCC) and it causes an exception 3. If you don’t have a
> debugger hooked in underneath  the exception 3 is going to get handled in
> the unexpected exception handler, and that is probably in the CPUD DXE
> driver or DXE Core or some such. So you are going to end up with the
> PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers it
> works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts a lot
> more like a JTAG hardware debugger than a pure software debugger. Also note
> that CpuDeadLoop() is an infinite loop, so you can modify the loop variable
> with the debugger to continue.
>
> I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
> attach gdb. Now after you have the target established load the symbols. The
> reason for me suggesting this flow is the debugger has a flexible concept of
> what the target is. If you load symbols that will create a target for a
> stock x86-64 image. When you connect to the QEMU gdb-remote there is a
> handshake that describes the target and what registers are available. I seem
> to remember QEMU exports some of the system registers, like the control
> registers, so it is an extended version of the x86-64 target. So this
> changing the target definition might confuse the debugger. To be safe I
> always connect 1st and then load symbols.
>
> The EFI images are PE/COFF relocatable executables that are linked around
> zero. They get loaded into memory and relocated, so that is why you need to
> specify the load address to get the symbols to resolve. One trick I use is
> to load the ELF (or PE/COFF) build output directly into the debugger. This
> lets you poke around the image at the linked address. You can disassemble
> the functions to see what they look like, obviously you can read any
> variables. This can be useful if you get the unhandled exception and it
> prints out the load address and offset (you can use the offset directly). It
> is also a good way to debug why your symbols are not quite loaded at the
> correct address, as you can see what bytes/instructions should be at a given
> address.
>
> Thanks,
>
> Andrew Fish
>
>>
>> --
>> Signed,
>> Ethin D. Probst
>>
>>
>> 
>>
>>
>
>


-- 
Signed,
Ethin D. Probst