From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by mx.groups.io with SMTP id smtpd.web11.3116.1623444515345268497 for ; Fri, 11 Jun 2021 13:48:35 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=r78TBxXn; spf=pass (domain: gmail.com, ip: 209.85.218.42, mailfrom: harlydavidsen@gmail.com) Received: by mail-ej1-f42.google.com with SMTP id ce15so6402979ejb.4 for ; Fri, 11 Jun 2021 13:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=P+q8mD849QcHB3NkNKLtamizDiugI/rcwSMt7108CIg=; b=r78TBxXnWmTfFbPsiJsN1bALY2H26EhIkG3BWDq8bVXWHAJNTey5LhBOGjNKTUtu50 gzJX3vSKrDBP5jPwaGTvx1ITe/RZjH/3jWrAh5ECNfnX3yAKwFtD1UKQ97dM+y+JhPly ZTOcTN/GQb9pl2mnFH7pgyQdEApKuuynSHiEF6XPWbOjJP5j8CZE7Jfl2Uw2aVFjNNQD QhpaTq26tms/IrIImqWl7f7ovNu8JhDAyiShMHv5YUdAoPCIjvVswB5kZv8WzwPjEBwm gFj7iiqwYU1MKoNjh7e+SgiqH4rETg7dGBFGBrtl1nKdeJFjTUcUzCuuwBiCG3YsYPWV citg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=P+q8mD849QcHB3NkNKLtamizDiugI/rcwSMt7108CIg=; b=q1dem4/Y2YHi19upi6j6BEmqYNis/Zqr2HPvxE7yqarAU7qrhDWuBFGLdXjiqytXto OBpl32LNoeEx2aBOreLlAjBzbDzuTKqJjgmcV/poxSK10m8xiTAc84N4ESaWPBeraFtn FCRb+nC92CqiqPnX7gbkYyPpMS2qgd4xcoTTxaB5hlBuEUj3h2JIAoxxvpQRgJXwHMkY 9L5v04557/2b1VqwKxrbqtzYJfHaDcXy7m+04mLEaTNUa+kPth2j2WlhDkxTtbr1TlOG F73TLDr0xMKSPERuZRf1/yvD34x74h1OmTX/de0zhM6/PXhzRIw+7wkVq+s4DuizO/Ks lLrQ== X-Gm-Message-State: AOAM533nGLzAepY5OO+PPBda9HcBMfY81VmVrBLkme5PJ5JALDzesnoD nVSKv88Z9mhSceNIDREvhTyhR/2gb7uS8wKImHQ= X-Google-Smtp-Source: ABdhPJzg1A4gEmedQzkXC9RpF+MtJtvlZBh1kCCm0DgL45xZ1CGdOERe/S3aoyBrSHMVObVVHv9e/CbqqaL98Z9be8Y= X-Received: by 2002:a17:906:3109:: with SMTP id 9mr5114203ejx.339.1623444513834; Fri, 11 Jun 2021 13:48:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:2490:0:0:0:0:0 with HTTP; Fri, 11 Jun 2021 13:48:33 -0700 (PDT) In-Reply-To: References: <0A1C6D8D-7F91-4038-B340-21104F14D00B@apple.com> From: "Ethin Probst" Date: Fri, 11 Jun 2021 15:48:33 -0500 Message-ID: Subject: Re: [edk2-devel] Help with debugging To: Andrew Fish Cc: edk2-devel-groups-io Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay, so I just tried exactly what you told me to do -- use CpuDeadLoop() and then just modify index to get out of it. Here's what I do in GDB: - Load the EFI application and connect via target remote :1234 - type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug 0x0007E4B8000` and answer yes when it prompts me to do so. (0x0007E4B8000 is the image base, the entry point is at 0x0007E4B9440.) - When I try to print the Index symbol, GDB tells me that it isn't in the current context. I feel like I'm missing something. I'm also not the best with GDB myself. = :) On 6/11/21, Andrew Fish wrote: > > >> On Jun 11, 2021, at 11:39 AM, Ethin Probst >> wrote: >> >> Hi Andrew, >> How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or >> does that work differently? >> > > Ethin, > > Lldb is the command line debugger that comes with Xcode on Mac. There is= no > gdb with Xcode, so I have to use lldb for my day job. > > Lldb can speak the gdb remote serial protocol: lldb -o =E2=80=9Cgdb-remo= te 9000=E2=80=9D > That assumes you passed `-gdb tcp::9000`to QEMU. > > Thanks, > > Andrew Fish > >> On 6/11/21, Andrew Fish > wrot= e: >>> >>> >>>> On Jun 11, 2021, at 10:06 AM, Ethin Probst >>>> 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=3Daudio -audiodev alsa,id=3Daudi= o -s >>>> -debugcon file:../debug.log -global isa-debugcon.iobase=3D0x402 >>>> -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=3Daudio -audiodev alsa,id=3Daudi= o -s >>>> -debugcon stdio -global isa-debugcon.iobase=3D0x402 >>>> - 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 >>>> Here's where everything breaks down. One of two things happens at thi= s >>>> point: >>>> 1. Either I get the wrong debug information (I get source code but th= e >>>> 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 si= t >>>> 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 ", 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 hav= e >>>> any advice? >>> >>> Ethin, >>> >>> Caveat emptor as I use lldb for my daily driver debugger so I might be= a >>> little off on gdb specifics=E2=80=A6. 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=E2= =80=99t 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 i= t >>> 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=E2=80=99d suggest a work flow of run your App/Driver, hit the CpuDea= dLoop(), >>> 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 conc= ept >>> 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 contro= l >>> 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 ne= ed >>> to >>> specify the load address to get the symbols to resolve. One trick I us= e >>> 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 i= t >>> prints out the load address and offset (you can use the offset directl= y). >>> It >>> is also a good way to debug why your symbols are not quite loaded at t= he >>> 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 >> >> >>=20 > > --=20 Signed, Ethin D. Probst