From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.apple.com [17.179.253.49]) by mx.groups.io with SMTP id smtpd.web10.9228.1623524615038626941 for ; Sat, 12 Jun 2021 12:03:35 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=gYyrZzbF; spf=pass (domain: apple.com, ip: 17.179.253.49, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 15CJ2qjg018522; Sat, 12 Jun 2021 12:03:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=hTbMUnDxFTsMIYX0Fokmkl2x/TEAu756b7gO2QlbIUU=; b=gYyrZzbF1MNTesIU5JRLL4a/WYoDp/fFjwR/BMtFhrdUORiUr8a6y//Pxfs+YpZ8mNnl jaRIfzi2sAQvv2J77umWeiHCgHNRL9Y9E9/yELRA541B95btKp6Y6nPVHt9kq0vaYohu lljqJDmtrte4Eu1QMEZJNvQWGj/bgGDX3de3b+mfapZL7dlDVyNSzp56vxRdjEzYsd4C z2imWQjfjkg8IiHgmf7nhujPxymf46sfF8t1/GlxzYe1lfb8MTc6QFlxMtpjQX0/r85x ebsYj6IbQuesVb/wKan4maiGfBuDtfBVTTg5AdZfOQ9ywO8zgXSrrFF1fmc9Nofrsjhw sg== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 394u7spk7f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 12 Jun 2021 12:03:34 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QUL007R9RLYYGB0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Sat, 12 Jun 2021 12:03:34 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QUL00L00RG8CX00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 12 Jun 2021 12:03:34 -0700 (PDT) X-Va-A: X-Va-T-CD: 494ba4982f0b5c44357f821690cbd4e9 X-Va-E-CD: c087f721d3a96ee8ad637b8e41fc3a56 X-Va-R-CD: b7e321ce675588393d108a7b4559214d X-Va-CD: 0 X-Va-ID: b0933e0b-ea26-49c8-ac23-ba0b91a3f444 X-V-A: X-V-T-CD: 494ba4982f0b5c44357f821690cbd4e9 X-V-E-CD: c087f721d3a96ee8ad637b8e41fc3a56 X-V-R-CD: b7e321ce675588393d108a7b4559214d X-V-CD: 0 X-V-ID: ba1a955f-02bd-49bc-b553-13da39b722e5 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-06-12_12:2021-06-11,2021-06-12 signatures=0 Received: from [17.235.9.157] (unknown [17.235.9.157]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QUL00J8BRLU8O00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 12 Jun 2021 12:03:34 -0700 (PDT) From: "Andrew Fish" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] Help with debugging Date: Sat, 12 Jun 2021 12:03:29 -0700 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> To: edk2-devel-groups-io , Ethin Probst In-reply-to: Message-id: X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-06-12_12:2021-06-11,2021-06-12 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_8BA9057C-C0B0-4405-A3E8-3FD82FB9E28B" --Apple-Mail=_8BA9057C-C0B0-4405-A3E8-3FD82FB9E28B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ethin, USB was designed in the 90=E2=80=99s and people actually worried about the= number of Si gates in a mouse, so a vast majority of the complexity of USB= is in the USB Host Controller (XHCI is the common host controller, aka HC= ). The devices are just end points on the bus. The end points are abstracte= d via the USB IO protocol. So you just need to match up the USB IO protocol= to the USB sub spec for audio devices. The XHCI complexity is abstracted v= ia a USB HC (Host Controller) driver that is consumed by the generic USB Bu= s driver that enumerates all the devices and produces USB IO. So you can ju= st treat the USB IO protocol as a black box.=20 So I think your 1st task is getting your Driver Bindging Supported() funct= ion matching on an audio endpoint you want to support. The Supported() will= need to return success before your Start() function is called. So maybe ta= ke a look at some example USB drivers that sit in the same layer in the sta= ck for different devices? [1] [1]=20 https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Usb/UsbMous= eDxe/UsbMouse.c#L68 https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Usb/UsbKbDx= e/EfiKey.c#L72 https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Usb/UsbMass= StorageDxe/UsbMassImpl.c#L706 Thanks, Andrew Fish > On Jun 11, 2021, at 9:47 PM, Ethin Probst wrot= e: >=20 > 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). >=20 > On 6/11/21, Andrew Fish > wrote= : >>=20 >>=20 >>> On Jun 11, 2021, at 4:29 PM, Ethin Probst >>> wrote: >>>=20 >>> Your suggestion of adding 0x240 worked. I'm able to successfully step >>> through the code now. Thank you! >>>=20 >>=20 >> OK that makes sense. The address in the add-symbol-file command is not = the >> load address of the image, but the start address of the text section. S= o >> that is why you had to add 0x240. >>=20 >> Sorry I had to work backwards from how it works, but maybe that info wi= ll be >> helpful for others? >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>> On 6/11/21, Andrew Fish >> wrote: >>>>=20 >>>>=20 >>>>> On Jun 11, 2021, at 2:29 PM, Ethin Probst > >>>>> wrote: >>>>>=20 >>>>> 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/UsbAud= io.c:72 >>>>> #1 ProcessModuleEntryPointList (SystemTable=3D0x7f9ee018, >>>>> ImageHandle=3D0x7e4f7518) at >>>>> /home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModule= Pkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300 >>>>> #2 _ModuleEntryPoint (ImageHandle=3D0x7e4f7518, SystemTable=3D0x7f9= ee018) >>>>> 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 function= s. >>>>> 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', NumEndp= oints >>>>> =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.= debug >>>>=20 >>>> OK that is interesting=E2=80=A6. +576 -> 0x240 witch is about the siz= e of the >>>> PE/COFF header. >>>>=20 >>>> For mach-O (macOS executables) we have to link at 0x240 to make space >>>> for >>>> the PE/COFF header in memory=E2=80=A6. >>>>=20 >>>> So the PE/COFF header starts at 0x7e4b8000 it is likely the text sect= ion >>>> 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. >>>>=20 >>>> 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? >>>>=20 >>>> Can you mail me a copy of UsbAudio.efi off list? I can take a quick >>>> look. >>>>=20 >>>> Thanks, >>>>=20 >>>> Andrew Fish >>>>=20 >>>>> The extra weird thing about this is that CpuDeadLoop() is at the sta= rt >>>>> of the UefiMain function, its not on line 72. The program doesn't ev= en >>>>> start there -- it starts by attempting to get the list of >>>>> EFI_USB_IO_PROTOCOL handles available. And GDB is making it look lik= e >>>>> its skipping all of that. >>>>>=20 >>>>> On 6/11/21, Andrew Fish > >>>>> >>> wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On Jun 11, 2021, at 1:48 PM, Ethin Probst >>>>>>> >> >>>>>>> wrote: >>>>>>>=20 >>>>>>> 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.de= bug >>>>>>> 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. >>>>>>> :) >>>>>>=20 >>>>>> What do you get from the following gdb commands? >>>>>> bt >>>>>> info local >>>>>> info symbol 0x0007E4B9440 >>>>>>=20 >>>>>> What exactly is gdb showing you? >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Andrew Fish >>>>>>=20 >>>>>>>=20 >>>>>>> On 6/11/21, Andrew Fish = > >>>>>>> >> >>>>>>> > >>>>>>> >>>> wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Jun 11, 2021, at 11:39 AM, Ethin Probst >>>>>>>>> = > >>>>>>>>> = >>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Hi Andrew, >>>>>>>>> How do you debug the EFI binary with LLDB? Can LLDB use GDB stub= s >>>>>>>>> or >>>>>>>>> does that work differently? >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Ethin, >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Lldb can speak the gdb remote serial protocol: lldb -o =E2=80=9Cg= db-remote >>>>>>>> 9000=E2=80=9D >>>>>>>> That assumes you passed `-gdb tcp::9000`to QEMU. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>> Andrew Fish >>>>>>>>=20 >>>>>>>>> On 6/11/21, Andrew Fish > >>>>>>>>> >> >>>>>>>>> > >>>>>>>>> >>> >>>>>>>>> > >>>>>>>>> >> >>>>>>>>> > >>>>>>>>> >>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On Jun 11, 2021, at 10:06 AM, Ethin Probst >>>>>>>>>>> > >>>>>>>>>>> >> >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hey all, >>>>>>>>>>>=20 >>>>>>>>>>> So Leif and I have discussed this at length but I thought I'd >>>>>>>>>>> reach >>>>>>>>>>> out to all of you for more help. >>>>>>>>>>>=20 >>>>>>>>>>> I'm having a lot of trouble debugging my UEFI app. Here's how = I >>>>>>>>>>> do >>>>>>>>>>> things: >>>>>>>>>>>=20 >>>>>>>>>>> - 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=3D0x40= 2 >>>>>>>>>>> -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 plac= ing >>>>>>>>>>> a >>>>>>>>>>> breakpoint (either software or hardware) has no effect; or >>>>>>>>>>> 2. If I use CpuBreakpoint(), the firmware gives me the registe= rs >>>>>>>>>>> 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 jum= p >>>>>>>>>>> into >>>>>>>>>>> my code without triggering a general protection exception or n= ot >>>>>>>>>>> actually causing anything to happen... You get the idea. >>>>>>>>>>>=20 >>>>>>>>>>> So I'm really, really confused on what's going wrong. Do you g= uys >>>>>>>>>>> have >>>>>>>>>>> any advice? >>>>>>>>>>=20 >>>>>>>>>> Ethin, >>>>>>>>>>=20 >>>>>>>>>> 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 b= e lldb >>>>>>>>>> centric. >>>>>>>>>>=20 >>>>>>>>>> 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 C= PUD >>>>>>>>>> DXE >>>>>>>>>> driver or DXE Core or some such. So you are going to end up wit= h >>>>>>>>>> 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 QEM= U >>>>>>>>>> acts >>>>>>>>>> a >>>>>>>>>> lot >>>>>>>>>> more like a JTAG hardware debugger than a pure software debugge= r. >>>>>>>>>> Also >>>>>>>>>> note >>>>>>>>>> that CpuDeadLoop() is an infinite loop, so you can modify the l= oop >>>>>>>>>> variable >>>>>>>>>> with the debugger to continue. >>>>>>>>>>=20 >>>>>>>>>> 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 flexib= le >>>>>>>>>> concept >>>>>>>>>> of >>>>>>>>>> what the target is. If you load symbols that will create a targ= et >>>>>>>>>> for >>>>>>>>>> a >>>>>>>>>> stock x86-64 image. When you connect to the QEMU gdb-remote the= re >>>>>>>>>> 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. S= o >>>>>>>>>> this >>>>>>>>>> changing the target definition might confuse the debugger. To b= e >>>>>>>>>> safe >>>>>>>>>> I >>>>>>>>>> always connect 1st and then load symbols. >>>>>>>>>>=20 >>>>>>>>>> The EFI images are PE/COFF relocatable executables that are lin= ked >>>>>>>>>> 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 tri= ck >>>>>>>>>> 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 rea= d >>>>>>>>>> any >>>>>>>>>> variables. This can be useful if you get the unhandled exceptio= n >>>>>>>>>> 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 load= ed >>>>>>>>>> at >>>>>>>>>> the >>>>>>>>>> correct address, as you can see what bytes/instructions should = be >>>>>>>>>> at >>>>>>>>>> a >>>>>>>>>> given >>>>>>>>>> address. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>>=20 >>>>>>>>>> Andrew Fish >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Signed, >>>>>>>>>>> Ethin D. Probst >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Signed, >>>>>>>>> Ethin D. Probst >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Signed, >>>>>>> Ethin D. Probst >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Signed, >>>>> Ethin D. Probst >>>>=20 >>>>=20 >>>=20 >>>=20 >>> -- >>> Signed, >>> Ethin D. Probst >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 > --=20 > Signed, > Ethin D. Probst >=20 >=20 >=20 --Apple-Mail=_8BA9057C-C0B0-4405-A3E8-3FD82FB9E28B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ethin,
USB was designed in the 90=E2=80=99s and = people actually worried about the number of Si gates in a mouse, so a vast = majority of the complexity of USB is in the USB Host Controller (XHCI is th= e common  host controller, aka HC). The devices are just end points on= the bus. The end points are abstracted via the USB IO protocol. So you jus= t need to match up the USB IO protocol to the USB sub spec for audio device= s. The XHCI complexity is abstracted via a USB HC (Host Controller) driver = that is consumed by the generic USB Bus driver that enumerates all the devi= ces and produces USB IO. So you can just treat the USB IO protocol as a bla= ck box. 

So = I think your 1st task is getting your Driver Bindging Supported() function = matching on an audio endpoint you want to support. The Supported() will nee= d to return success before your Start() function is called. So maybe take a= look at some example USB drivers that sit in the same layer in the stack f= or different devices? [1]

[1] 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Usb/U= sbMouseDxe/UsbMouse.c#L68
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus= /Usb/UsbKbDxe/EfiKey.c#L72
https://github.com/tianocore/edk2/blob/master/= MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c#L706

Thanks,
<= br class=3D"">
Andrew Fish

On Jun 11, 2021= , at 9:47 PM, Ethin Probst <harlydavidsen@gmail.com> wrote:

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 jus= t be my
inexperience wi= th USB/XHCI showing).

On 6/11/21, Andrew Fish <afish@apple.com> wrote:


On Jun 11, 2021, at 4:29 PM, Ethin Probst <harlydavidsen@gmail.com= >
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 the
load address of the image, but the start address of t= he 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 will be
helpful for others?
Thanks,

Andrew Fish
=
On 6/11/21, Andrew Fish= <afish@apple.com <mailto:afish@apple.com>> wrote:


On Jun 11, 2021, at 2:29 PM, Ethin Probst &l= t;harlydavidsen@gmail= .com>
wrote:

Initial conn= ection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from f= ile
"Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug"
at
.text_addr =3D 0x7e4b8000
Reading symbols fro= m Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding = full symbols from
Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.deb= ug...
Backtrace:
#0  0x000000007e4b9517 in= UefiMain (st=3D0x7f9ee018,
imageHandle=3D0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/Usb= Audio.c:72
#1  ProcessModuleEntryPointList (SystemTable= =3D0x7f9ee018,
ImageHandle=3D0x7e4f7518) at
/h= ome/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Appli= cation/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2  _Module= EntryPoint (ImageHandle=3D0x7e4f7518, SystemTable=3D0x7f9ee018)
at
/home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicat= ionEntryPoint/ApplicationEntryPoint.c:59
#3  0x000000007= fead316 in ?? ()
#4  0x000000007e4f7518 in ?? ()
#5  0x000000007feab5c7 in ?? ()
#6  0x000000= 007fea3520 in ?? ()
#7  0x0000000101000000 in ?? ()
#8  0x0000000000000030 in ?? ()
#9  0x000= 000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea352= 8 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 = 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()#16 0x000000007e3abfca in ?? ()
#17 0x000000007e= 4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 = /** @file
2   G= CC inline implementation of BaseLib processor specific functions.
3 =
4=   Copyright = (c) 2006 - 2020, Intel Corporation. All rights
reserved.<B= R>
5   Porti= ons copyright (c) 2008 - 2009, Apple Inc. All rights
reserved= .<BR>
6   = ;SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9 =
10
Attempt to use "next":
72 } else if (interfa= ceDescriptor.InterfaceClass =3D=3D 0x01 &&
interfaceD= escriptor.InterfaceSubClass =3D=3D 0x03) {
(This is my code b= ut 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 '\0= 01', AlternateSetting =3D 0 '\000', NumEndpoints
=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 <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in secti= on .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG= _GCC5/X64/UsbAudio.debug

OK that = is interesting=E2=80=A6. +576 -> 0x240 witch is about the size of thePE/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 section<= br class=3D"">starts at 0x7e4b8240? So try adding 0x240 to the load address= on the
add-symbol-file command. If that does not work trip s= ubtracting 0x240
from
the load address.

We would need to dump out the UsbAudio.efi file to fi= gure out exactly
what
is going on. What distro = are you on? Do you have the readpe utility? I=E2=80=99m
notsure what you can dump with objcopy?

Can you mail me a copy of UsbAudio.efi off list? I can take a quick<= br class=3D"">look.

Thanks,

Andrew Fish

The extra weird thing about this is that CpuDeadLoop() is at = the start
of the UefiMain function, its not on line 72. The p= rogram doesn't even
start there -- it starts by attempting to= get the list of
EFI_USB_IO_PROTOCOL handles available. And G= DB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@apple.com <mailto:af= ish@apple.com>
<mailto:afish@apple.com=  <mailto:afish= @apple.com>>> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gm= ail.com>>
wrote:

Okay,= so I just tried exactly what you told me to do -- use
CpuDea= dLoop() and then just modify index to get out of it. Here's
w= hat
I do in GDB:
- Load the EFI application and= connect via target remote :1234
- type `add-symbol-file Buil= d/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 i= n
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 fo= llowing gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is g= db showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@apple.com <mailto= :afish@apple.com>
<mailto:afish@apple.com <mailto:af= ish@apple.com>>
<mailto:afish@apple.com <mailto:a= fish@apple.com>
<mailto:afish@apple.com <mailto:afis= h@apple.com>>>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@gmail.com
= <mailto:harlydavid= sen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
wr= ote:

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 li= ne debugger that comes with Xcode on Mac.
There
is
no
gdb with Xcode, so I have to use lldb fo= r my day job.

Lldb can speak the gdb remote se= rial protocol: lldb -o =E2=80=9Cgdb-remote
9000=E2=80=9D
That assumes you passed `-gdb tcp::9000`to QEMU.
Thanks,

Andrew Fish

On 6/11/21, Andrew Fis= h <afish@apple.com <mailto:afish@apple.com>
<mailto:afish@apple.com <mailto:afish@apple.com>>
<mailto:afish@apple.com <mailto:afish@apple.com>
<mailto:afish@apple.com <mailto:afish@apple.com>>>
<<= a href=3D"mailto:afish@apple.com" class=3D"">mailto:afish@apple.com <mailto:afish@apple.com>
<mailto:afish@apple.com <mailto:afish@apple.com>>
<mailto:afish@apple.com <mailto:afish@apple.com>
<mailto:afish@apple.com <mailto:afish@apple.com>>>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin = Probst
<harlydavidsen@gmail.com&nb= sp;<mailto:= harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
<mailto:har= lydavidsen@gmail.com = <mailto:harlydavid= sen@gmail.com>
<mailto:harlydavidsen@gmail.com
<mailto:harlydavidsen@gma= il.com>>>>
wrote:

Hey all,

So Leif and I have discussed this a= t 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://gith= ub.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run= >
<https://github.com/Richard-W/uefi-run
<https://github.com/R= ichard-W/uefi-run>>
<https://github.com/Richard-W/uefi-run=
<https://github.com/Richard-W/uefi-run>
<https://github.com= /Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>&g= t;>) 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
-de= bugcon 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-a= udio,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 <image base>
H= ere's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong de= bug 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 give= s me the registers
and
the image base and entry= point addresses, and then appears to
just
sit<= br class=3D"">there waiting for something. Once I load the symbols using th= e
image
base it gives me, I can't actually do a= nything in the debugger; I
can't list code because I get "1 i= n <artificial>", I can't jump
into
my cod= e without triggering a general protection exception or not
ac= tually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys<= br class=3D"">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 te= rminology may be lldb
centric.

E= asy one 1st. When you run on top of a debugger using
CpuBreak= point()
works
great as the debugger hides its s= elf from you. On x86
CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exceptio= n 3. If you
don=E2=80=99t
have
a<= br class=3D"">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 withthe
PC/IP/RIP in the wrong driver. A lot of time= s for hardware
debuggers
it
works= better to use CpuDeadLoop(). The gdb-remote stub from QEMU
a= cts
a
lot
more like a JTAG hardwa= re debugger than a pure software debugger.
Also
note
that CpuDeadLoop() is an infinite loop, so you can modi= fy the loop
variable
with the debugger to conti= nue.

I=E2=80=99d suggest a work flow of run yo= ur App/Driver, hit the
CpuDeadLoop(),
attach gd= b. 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 conn= ect to the QEMU gdb-remote there
is
a
handshake that describes the target and what registers are
available.
I
seem
to remem= ber QEMU exports some of the system registers, like the
contr= ol
registers, so it is an extended version of the x86-64 targ= et. So
this
changing the target definition migh= t 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 relocat= ed, so that is why
you
need
tospecify the load address to get the symbols to resolve. One tri= ck
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 li= nked 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 exceptionand
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, a= s you can see what bytes/instructions should be
at
a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst

<= br class=3D"">





--Signed,
Ethin D. Probst







--
Signed,<= br class=3D"">Ethin D. Probst


<= br class=3D"">




--
Signed,
Ethin D. Pr= obst


=

--
Signed,
Ethin = D. Probst







-- 
Signed,
Ethin D. Probst



--Apple-Mail=_8BA9057C-C0B0-4405-A3E8-3FD82FB9E28B--