From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.apple.com [17.179.253.48]) by mx.groups.io with SMTP id smtpd.web08.771.1623452951571703740 for ; Fri, 11 Jun 2021 16:09:11 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=ZS23OcdJ; spf=pass (domain: apple.com, ip: 17.179.253.48, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 15BN8IqB008561; Fri, 11 Jun 2021 16:09:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=NncVPg2oW3BYILQzmT0R6bdkKBdZJFG9ylOkT6F0Kqg=; b=ZS23OcdJZWBepfSfEVcA7O4KvR1I5nsAGalYlku1GTMQ7gaAaOKssN/d3SrNFeJfEBxA mSIlD6Bp3/qCL9QuhrLuFR8oX0vJhcWRdDli0zEthCZqlodrw2P6H/f9LhHuT53eaTsi E7rxTb2Kp8GadUorlyTBnjEmyf7ajIa4hV95AcqJj2ypMNF31luXittUWd0Axmxg/vZj KOXzSaAHrkOTyhbWtj7cOEReqT8IppvtHnY/IPu0NjmM+IovVEvxn5G42g4HlEqR8ZLu ho5I14q4tjhf+AwtcQ5IwfpQi1j1CaxQz9echkMqa0ukeil2ZW1uYTxHaOitNGMNAT6a +A== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 393h32w9dy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 11 Jun 2021 16:09:11 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QUK00DER8BBG980@rn-mailsvcp-mta-lapp03.rno.apple.com>; Fri, 11 Jun 2021 16:09:11 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QUK0080081B0N00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 11 Jun 2021 16:09:11 -0700 (PDT) X-Va-A: X-Va-T-CD: b2a6e213b1e93bac3561a11ee6934d40 X-Va-E-CD: c087f721d3a96ee8ad637b8e41fc3a56 X-Va-R-CD: b7e321ce675588393d108a7b4559214d X-Va-CD: 0 X-Va-ID: 50b0f6a7-3c0d-41fd-b37c-92c7c3e0d138 X-V-A: X-V-T-CD: b2a6e213b1e93bac3561a11ee6934d40 X-V-E-CD: c087f721d3a96ee8ad637b8e41fc3a56 X-V-R-CD: b7e321ce675588393d108a7b4559214d X-V-CD: 0 X-V-ID: 8ed613f0-ade0-4e33-86e1-bb59eafce385 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-06-11_06:2021-06-11,2021-06-11 signatures=0 Received: from [17.235.24.70] (unknown [17.235.24.70]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QUK011G08B6VA00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 11 Jun 2021 16:09:10 -0700 (PDT) From: "Andrew Fish" Message-id: <7E2BF7B0-131E-44EC-92D3-2341CEC9D9BE@apple.com> MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] Help with debugging Date: Fri, 11 Jun 2021 16:09:06 -0700 In-reply-to: Cc: edk2-devel-groups-io To: Ethin Probst References: <0A1C6D8D-7F91-4038-B340-21104F14D00B@apple.com> <62AF91AB-7008-4DBA-86A6-F24F3F584B16@apple.com> 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-11_06:2021-06-11,2021-06-11 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_71D5499F-3766-4321-9A51-3CC8925F267F" --Apple-Mail=_71D5499F-3766-4321-9A51-3CC8925F267F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 11, 2021, at 2:29 PM, Ethin Probst wrot= e: >=20 > Initial connection and loading symbols: > Remote debugging using :1234 > 0x000000007e4b9517 in ?? () > add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debu= g" 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.debu= g... > Backtrace: > #0 0x000000007e4b9517 in UefiMain (st=3D0x7f9ee018, > imageHandle=3D0x7e4f7518) at > /home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c= :72 > #1 ProcessModuleEntryPointList (SystemTable=3D0x7f9ee018, > ImageHandle=3D0x7e4f7518) at > /home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/= Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300 > #2 _ModuleEntryPoint (ImageHandle=3D0x7e4f7518, SystemTable=3D0x7f9ee01= 8) > 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.<= BR> > 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', NumEndpoint= s > =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.debu= g OK that is interesting=E2=80=A6. +576 -> 0x240 witch is about the size 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. So the PE/COFF header starts at 0x7e4b8000 it is likely the text section s= tarts at 0x7e4b8240? So try adding 0x240 to the load address on the add-sym= bol-file command. If that does not work trip subtracting 0x240 from the loa= d 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? Can you mail me a copy of UsbAudio.efi off list? I can take a quick look.= =20 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 program doesn't even > 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. >=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.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 myse= lf. >>> :) >>=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 stubs 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=9Cgdb-r= emote 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 reac= h >>>>>>> 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 -devi= ce >>>>>>> qemu-xhci -device usb-audio,audiodev=3Daudio -audiodev alsa,id=3Da= udio -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 -devi= ce >>>>>>> qemu-xhci -device usb-audio,audiodev=3Daudio -audiodev alsa,id=3Da= udio -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 placing = a >>>>>>> breakpoint (either software or hardware) has no effect; or >>>>>>> 2. If I use CpuBreakpoint(), the firmware gives me the registers a= nd >>>>>>> the image base and entry point addresses, and then appears to just >>>>>>> sit >>>>>>> there waiting for something. Once I load the symbols using the ima= ge >>>>>>> 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 in= to >>>>>>> my code without triggering a general protection exception or not >>>>>>> actually causing anything to happen... You get the idea. >>>>>>>=20 >>>>>>> So I'm really, really confused on what's going wrong. Do you guys >>>>>>> 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 be ll= db 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 hand= led >>>>>> 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 th= e >>>>>> PC/IP/RIP in the wrong driver. A lot of times for hardware debugger= s >>>>>> it >>>>>> works better to use CpuDeadLoop(). The gdb-remote stub from QEMU ac= ts >>>>>> a >>>>>> lot >>>>>> more like a JTAG hardware debugger than a pure software debugger. A= lso >>>>>> note >>>>>> that CpuDeadLoop() is an infinite loop, so you can modify the loop >>>>>> variable >>>>>> with the debugger to continue. >>>>>>=20 >>>>>> I=E2=80=99d suggest a work flow of run your App/Driver, hit the Cpu= DeadLoop(), >>>>>> 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 f= or >>>>>> a >>>>>> stock x86-64 image. When you connect to the QEMU gdb-remote there i= s a >>>>>> handshake that describes the target and what registers are availabl= e. >>>>>> 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 th= is >>>>>> changing the target definition might confuse the debugger. To be sa= fe >>>>>> I >>>>>> always connect 1st and then load symbols. >>>>>>=20 >>>>>> 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 debugge= r. >>>>>> 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 an= y >>>>>> variables. This can be useful if you get the unhandled exception an= d >>>>>> 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 a= t >>>>>> the >>>>>> correct address, as you can see what bytes/instructions should be a= t 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 > --=20 > Signed, > Ethin D. Probst --Apple-Mail=_71D5499F-3766-4321-9A51-3CC8925F267F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 11, 2= 021, at 2:29 PM, Ethin Probst <harlydavidsen@gmail.com> wrote:

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/Mde= Module/DEBUG_GCC5/X64/UsbAudio.debug" at
.text_addr =3D 0x7e4b8000
<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size:= 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; text-align: start; text-indent: 0px; text-transform= : none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px; text-decoration: none; float: none; display: inline !important;" class= = =3D"">Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug..= .
Expanding full symbol= s from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0  0x000000007e4b9517 in UefiMain (st=3D0x7f9ee0= 18,
imageHandle=3D0x7e4= f7518) at
/home/ethin/s= ource/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1  ProcessModuleEntryPointLis= t (SystemTable=3D0x7f9ee018,
<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size:= 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; text-align: start; text-indent: 0px; text-transform= : none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px; text-decoration: none; float: none; display: inline !important;" class= = =3D"">ImageHandle=3D0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/Md= eModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2  _ModuleEntryPoint (ImageHand= le=3D0x7e4f7518, SystemTable=3D0x7f9ee018)
at /home/ethin/source/edk/edk2/MdePkg/Library/UefiAppli= cationEntryPoint/ApplicationEntryPoint.c:59
#3  0x000000007fead316 in ?? ()
#4  0x000000007e4f7518 in ?? ()<= /span>
#5  0x000000007fea= b5c7 in ?? ()
#6  = 0x000000007fea3520 in ?? ()
#7  0x0000000101000000 in ?? ()
#8  0x0000000000000030 in ?? ()
#9  0x000000007e4f6018 in ?? ()<= /span>
#10 0x000000007e60a918 = in ?? ()
#11 0x00000000= 0000011d in ?? ()
#12= 0x000000007fea3528 in ?? ()
<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size:= 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; text-align: start; text-indent: 0px; text-transform= : none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px; text-decoration: none; float: none; display: inline !important;" class= = =3D"">#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()#17 0x000000007e4f7418 in ?? ()<= /span>
#18 0x000000007fea3528 = in ?? ()
#19 0x00000000= 00000000 in ?? ()
Sou= rce-code listing:
1 /**= @file
2   GCC inline implementation of BaseL= ib processor specific functions.
3
4   Copyright (c) 2006 - 2020, Intel Corporation= . All rights reserved.<BR>
5   Portions= 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 (interfaceDescriptor.InterfaceClass =3D=3D 0x01 &&=
interfaceDescriptor.In= terfaceSubClass =3D=3D 0x03) {
(This is my code but it continuously prints this same line over and=
over every time "next"= is used.)
Attempt to u= se "print Index":
No = symbol "Index" in current context.
info local:
UsbIo =3D 0x0
int= erfaceDescriptor =3D {Length =3D 0 '\000', DescriptorType =3D 8 '\b',
InterfaceNumber =3D 1 '\001'= , AlternateSetting =3D 0 '\000', NumEndpoints
=3D 0 '\000', InterfaceClass =3D 0 '\000', Interface= SubClass =3D 0 '\000',
= InterfaceProtocol =3D 0 '\000',
 Interface =3D 0 '\000'}
i =3D 2118887920
numHandles =3D 264
<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size:= 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; text-align: start; text-indent: 0px; text-transform= : none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px; text-decoration: none; float: none; display: inline !important;" class= = =3D"">handles =3D 0x4
= status =3D <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/Mde= Module/DEBUG_GCC5/X64/UsbAudio.debug

OK that is interes= ting=E2=80=A6. +576 -> 0x240 witch is about the size of the PE/COFF head= er. 

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 start= s at 0x7e4b8000 it is likely the text section starts at 0x7e4b8240? So try = adding 0x240 to the load address on the add-symbol-file command. If that do= es not work trip subtracting 0x240 from the load address. 
<= br class=3D"">
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 t= he 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. 

T= hanks,

Andrew Fish

Th= e extra weird thing about this is that CpuDeadLoop() is at the start=
of the UefiMain function, its= not on line 72. The program doesn't even
start there -- it starts by attempting to get the list o= f
EFI_USB_IO_PROTOCOL h= andles available. And GDB is making it look like
its skipping all of that.

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


On Jun 11, 2021,= at 1:48 PM, Ethin Probst <harlydavidsen@gmail.com>
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. H= ere's what
I do in GDB:
- Load the EFI applicat= ion and connect via target remote :1234
- type `add-symbol-fi= le Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B800= 0` 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 miss= ing something. I'm also not the best with GDB myself.
:)

What do you get from the following gd= b commands?
bt
info local
info sy= mbol 0x0007E4B9440

What exactly is gdb showing= you?

Thanks,

And= rew Fish

=
On 6/11/21, Andrew Fish <afish@apple.com&nbs= p;<mailto:afish@app= le.com>> wrote:


On Jun= 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@gmail.com>
wrote:
Hi Andrew,
How do you debug the EF= I 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 ca= n speak the gdb remote serial 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 Fish <afish@apple= .com <mailto:afish@apple.com>
<mailto:afish@apple= .com <mailto:afish@apple.com>>> wr= ote:


On Jun 11, 2021, at 10:06 A= M, Ethin Probst <h= arlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach<= br class=3D"">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
<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/Ovmf= X64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qe= mu-xhci -device usb-audio,audiodev=3Daudio -audiodev alsa,id=3Daudio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=3D0x402<= br class=3D"">-nographic
Or:
uefi-run -b Build/= OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Sh= ell.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 &= lt;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 sy= stem and placing a
breakpoint (either software or hardware) h= as no effect; or
2. If I use CpuBreakpoint(), the firmware gi= ves me the registers and
the image base and entry point addre= sses, and then appears to just
sit
there waitin= g 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 goin= g wrong. Do you guys
have
any advice?

Ethin,

Cave= at 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 termin= ology 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 CpuBreakpoi= nt()
is
an
INT 3h instruction (0x= CC) and it causes an exception 3. If you don=E2=80=99t
havea
debugger hooked in underneath  the except= ion 3 is going to get handled
in
the unexpected= exception handler, and that is probably in the CPUD DXE
driv= er 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=E2=80=99d suggest a work flow = of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. No= w after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debu= gger has a flexible
concept
of
wh= at 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 wh= at 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 conne= ct 1st and then load symbols.

The EFI images a= re 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 addr= ess 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 th= e 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 excep= tion and
it
prints out the load address and off= set (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 byt= es/instructions should be at a
given
address.
Thanks,

Andrew Fis= h


--
Signed,
Ethin D. Probst








--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst

<= br class=3D"">




-- 
Signed,
Ethin D. Probst

--Apple-Mail=_71D5499F-3766-4321-9A51-3CC8925F267F--