> On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavid...@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
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76404): https://edk2.groups.io/g/devel/message/76404
Mute This Topic: https://groups.io/mt/83473484/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
