From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by mx.groups.io with SMTP id smtpd.web09.2506.1623473272941944974 for ; Fri, 11 Jun 2021 21:47:53 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cdHGhIQF; spf=pass (domain: gmail.com, ip: 209.85.208.50, mailfrom: harlydavidsen@gmail.com) Received: by mail-ed1-f50.google.com with SMTP id t3so39462383edc.7 for ; Fri, 11 Jun 2021 21:47:52 -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=1sBxPK/0taAIN/K6cOCYh8+jQh7rKROwUk7Da20GBMg=; b=cdHGhIQFDK1gWQaBhQYNP4Xum/1nVU0ETmK12KxFJZdY9P8Fxzvnc3+56aebpYkrCm R0dmQoAga35UB9bkLEAixYud7MWXiX4WTmZ852QcC3biDeek3NhpOZs7NL2aVgA84Xcx z2RHRcAge6h0QKb4LA0hQjJBT6/BgR46rpmu4U/zh2j2zmAAOnFohyMFvlV1JC8+mrRY FIKMDlKGN14bTtq+TYTfJZCLgieD2IYW+8YrslpTT0dNGRjC6CNNR/Wr3fXaPyJAQd/i 6MLZLE3KabgKGtOSCGHJ10SFxVYB9rAR+sUEHWjf5JY3npLN4QLMoq/RXGaBskcpm7gN PREA== 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=1sBxPK/0taAIN/K6cOCYh8+jQh7rKROwUk7Da20GBMg=; b=Mxf73xx+t9sooExt0XYstdYWOLaNmBIbF8YgrzymLH3iWJpnBV+yEHyKnJWx1355yL 50diHdiqVCL4wK6xV9+EoPdZEe3cDD4wRIIcsQB9rgPZ3s3oKDto7JecjBgKdHMJA1lI pBgVwXzAywWU5uc4atIZHNYXDunPs086PvZdt4a3lEOcKJC05A75FsI7LyVmuFiA6FPe SdLCyZKfCHlNQbmiVw7QLcu1yh9SuFKes+rEycu+EhslZlg5gNndEF3RlyT0LGai8mS7 ssEi+X+8htJgn40Wk1VGQMgkX4w14gL+LFO12zeXEP4D1w54fN9dyqau/xctjKW08QCn ZX6A== X-Gm-Message-State: AOAM530orKyVmmqa4h5JeaYVS/WWlOXSI6AKkEkkIPtRVEtg7CgEX7eq VqsC+vKyiEJS0xiZSY13tWaiDb4JlEuo6H9s7OM= X-Google-Smtp-Source: ABdhPJxRuUA8dQwZfksCtNnViJifLApVkgwMm9PvrPgyeQ+SWLjvQvp/75AlXNIDLKClN1hAEgm9MLTUYoUaqDA/QlU= X-Received: by 2002:a05:6402:188:: with SMTP id r8mr6916226edv.75.1623473271318; Fri, 11 Jun 2021 21:47:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:2490:0:0:0:0:0 with HTTP; Fri, 11 Jun 2021 21:47:50 -0700 (PDT) In-Reply-To: <38BB1DF8-B608-41AA-81A3-2E68845FF450@apple.com> References: <0A1C6D8D-7F91-4038-B340-21104F14D00B@apple.com> <62AF91AB-7008-4DBA-86A6-F24F3F584B16@apple.com> <7E2BF7B0-131E-44EC-92D3-2341CEC9D9BE@apple.com> <38BB1DF8-B608-41AA-81A3-2E68845FF450@apple.com> From: "Ethin Probst" Date: Fri, 11 Jun 2021 23:47:50 -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 Yeah, maybe. Now I just have to figure out where to even begin with USB audio. The specs aren't useful in determining where to begin -- or at least they aren't from my POV (though that might just be my inexperience with USB/XHCI showing). On 6/11/21, Andrew Fish wrote: > > >> On Jun 11, 2021, at 4:29 PM, Ethin Probst >> wrote: >> >> Your suggestion of adding 0x240 worked. I'm able to successfully step >> through the code now. Thank you! >> > > OK that makes sense. The address in the add-symbol-file command is not t= he > load address of the image, but the start address of the text section. So > that is why you had to add 0x240. > > Sorry I had to work backwards from how it works, but maybe that info wil= l be > helpful for others? > > Thanks, > > Andrew Fish > >> On 6/11/21, Andrew Fish > wrot= e: >>> >>> >>>> On Jun 11, 2021, at 2:29 PM, Ethin Probst >>>> wrote: >>>> >>>> Initial connection and loading symbols: >>>> Remote debugging using :1234 >>>> 0x000000007e4b9517 in ?? () >>>> add symbol table from file >>>> "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug" >>>> at >>>> =09.text_addr =3D 0x7e4b8000 >>>> Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug... >>>> Expanding full symbols from >>>> Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug... >>>> Backtrace: >>>> #0 0x000000007e4b9517 in UefiMain (st=3D0x7f9ee018, >>>> imageHandle=3D0x7e4f7518) at >>>> /home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudi= o.c:72 >>>> #1 ProcessModuleEntryPointList (SystemTable=3D0x7f9ee018, >>>> ImageHandle=3D0x7e4f7518) at >>>> /home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModuleP= kg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300 >>>> #2 _ModuleEntryPoint (ImageHandle=3D0x7e4f7518, SystemTable=3D0x7f9e= e018) >>>> at >>>> /home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/= ApplicationEntryPoint.c:59 >>>> #3 0x000000007fead316 in ?? () >>>> #4 0x000000007e4f7518 in ?? () >>>> #5 0x000000007feab5c7 in ?? () >>>> #6 0x000000007fea3520 in ?? () >>>> #7 0x0000000101000000 in ?? () >>>> #8 0x0000000000000030 in ?? () >>>> #9 0x000000007e4f6018 in ?? () >>>> #10 0x000000007e60a918 in ?? () >>>> #11 0x000000000000011d in ?? () >>>> #12 0x000000007fea3528 in ?? () >>>> #13 0x000000007e4f7818 in ?? () >>>> #14 0x000000007e4f7c98 in ?? () >>>> #15 0x000000007fea3538 in ?? () >>>> #16 0x000000007e3abfca in ?? () >>>> #17 0x000000007e4f7418 in ?? () >>>> #18 0x000000007fea3528 in ?? () >>>> #19 0x0000000000000000 in ?? () >>>> Source-code listing: >>>> 1 /** @file >>>> 2 GCC inline implementation of BaseLib processor specific functions= . >>>> 3=09 >>>> 4 Copyright (c) 2006 - 2020, Intel Corporation. All rights >>>> reserved.
>>>> 5 Portions copyright (c) 2008 - 2009, Apple Inc. All rights >>>> reserved.
>>>> 6 SPDX-License-Identifier: BSD-2-Clause-Patent >>>> 7=09 >>>> 8 **/ >>>> 9=09 >>>> 10=09 >>>> Attempt to use "next": >>>> 72 } else if (interfaceDescriptor.InterfaceClass =3D=3D 0x01 && >>>> interfaceDescriptor.InterfaceSubClass =3D=3D 0x03) { >>>> (This is my code but it continuously prints this same line over and >>>> over every time "next" is used.) >>>> Attempt to use "print Index": >>>> No symbol "Index" in current context. >>>> info local: >>>> UsbIo =3D 0x0 >>>> interfaceDescriptor =3D {Length =3D 0 '\000', DescriptorType =3D 8 '\= b', >>>> InterfaceNumber =3D 1 '\001', AlternateSetting =3D 0 '\000', NumEndpo= ints >>>> =3D 0 '\000', InterfaceClass =3D 0 '\000', InterfaceSubClass =3D 0 '\= 000', >>>> InterfaceProtocol =3D 0 '\000', >>>> Interface =3D 0 '\000'} >>>> i =3D 2118887920 >>>> numHandles =3D 264 >>>> handles =3D 0x4 >>>> status =3D >>>> info symbol 0x0007E4B9440: >>>> _ModuleEntryPoint + 576 in section .text of >>>> /home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.d= ebug >>> >>> OK that is interesting=E2=80=A6. +576 -> 0x240 witch is about the size= of the >>> PE/COFF header. >>> >>> For mach-O (macOS executables) we have to link at 0x240 to make space >>> for >>> the PE/COFF header in memory=E2=80=A6. >>> >>> So the PE/COFF header starts at 0x7e4b8000 it is likely the text secti= on >>> starts at 0x7e4b8240? So try adding 0x240 to the load address on the >>> add-symbol-file command. If that does not work trip subtracting 0x240 >>> from >>> the load address. >>> >>> We would need to dump out the UsbAudio.efi file to figure out exactly >>> what >>> is going on. What distro are you on? Do you have the readpe utility? I= = =E2=80=99m >>> not >>> sure what you can dump with objcopy? >>> >>> Can you mail me a copy of UsbAudio.efi off list? I can take a quick >>> look. >>> >>> Thanks, >>> >>> Andrew Fish >>> >>>> The extra weird thing about this is that CpuDeadLoop() is at the star= t >>>> of the UefiMain function, its not on line 72. The program doesn't eve= n >>>> start there -- it starts by attempting to get the list of >>>> EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like >>>> its skipping all of that. >>>> >>>> On 6/11/21, Andrew Fish >>>> >> wrote: >>>>> >>>>> >>>>>> On Jun 11, 2021, at 1:48 PM, Ethin Probst >>>>> > >>>>>> wrote: >>>>>> >>>>>> 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.deb= ug >>>>>> 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. >>>>>> :) >>>>> >>>>> What do you get from the following gdb commands? >>>>> bt >>>>> info local >>>>> info symbol 0x0007E4B9440 >>>>> >>>>> What exactly is gdb showing you? >>>>> >>>>> Thanks, >>>>> >>>>> Andrew Fish >>>>> >>>>>> >>>>>> 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=9Cgd= b-remote >>>>>>> 9000=E2=80=9D >>>>>>> That assumes you passed `-gdb tcp::9000`to QEMU. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Andrew Fish >>>>>>> >>>>>>>> On 6/11/21, Andrew Fish >>>>>>>> > >>>>>>>> >>>>>>>> >> >>>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> >>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> 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=3Daudio >>>>>>>>>> -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=3Daudio >>>>>>>>>> -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 >>>>>>>>>> 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 placi= ng >>>>>>>>>> a >>>>>>>>>> breakpoint (either software or hardware) has no effect; or >>>>>>>>>> 2. If I use CpuBreakpoint(), the firmware gives me the register= s >>>>>>>>>> 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 ", I can't jump >>>>>>>>>> into >>>>>>>>>> my code without triggering a general protection exception or no= t >>>>>>>>>> actually causing anything to happen... You get the idea. >>>>>>>>>> >>>>>>>>>> So I'm really, really confused on what's going wrong. Do you gu= ys >>>>>>>>>> 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=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 CP= UD >>>>>>>>> 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 lo= op >>>>>>>>> variable >>>>>>>>> with the debugger to continue. >>>>>>>>> >>>>>>>>> I=E2=80=99d 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 flexibl= e >>>>>>>>> concept >>>>>>>>> of >>>>>>>>> what the target is. If you load symbols that will create a targe= t >>>>>>>>> for >>>>>>>>> a >>>>>>>>> stock x86-64 image. When you connect to the QEMU gdb-remote ther= e >>>>>>>>> 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 link= ed >>>>>>>>> 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 tric= k >>>>>>>>> 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 loade= d >>>>>>>>> at >>>>>>>>> the >>>>>>>>> correct address, as you can see what bytes/instructions should b= e >>>>>>>>> at >>>>>>>>> a >>>>>>>>> given >>>>>>>>> address. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Andrew Fish >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Signed, >>>>>>>>>> Ethin D. Probst >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Signed, >>>>>>>> Ethin D. Probst >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Signed, >>>>>> Ethin D. Probst >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Signed, >>>> Ethin D. Probst >>> >>> >> >> >> -- >> Signed, >> Ethin D. Probst >> >> >>=20 > > --=20 Signed, Ethin D. Probst