From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.apple.com [17.179.253.44]) by mx.groups.io with SMTP id smtpd.web12.338.1623455292930005246 for ; Fri, 11 Jun 2021 16:48:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=fbGHx1Wo; spf=pass (domain: apple.com, ip: 17.179.253.44, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 15BNgZ3k003537; Fri, 11 Jun 2021 16:48:12 -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=HQGKTQxxGNkbDOe+lCpLTEWENu0WL0W3IYnvHpmXZjA=; b=fbGHx1WoHzbFdjXxxex1Gn7re6ghJC6VKQEnNiJqZyWBDoK8BWOQ5H/SKrkkqqBrtLXR 3dk/5X1zX1mfJ/HKJr3doBOU+CJtNsdV2JSqDC4ilvC6nO1IvV/3+r7t0yOZ6M2KOXVT 0zbckBjDHzvr7jzFCdDg9kN7hWsU+VJrsgMlPu4wHAHXvyAzdD5G+EO5hW/Ez5/YnQBs ELAZju7BUfg5GuXLVRbw6A7FoKERE/vSUQVUt3BsTDBgSVDGqjHUL/gxFZw32w7szn7J tjvdGCrxoivXMwa5TxF0xIKGbQC5BFQNxwY2Abp1xyDEj6QlsNTVI3HMOw8UjKBr4zNH 9Q== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 393m691ujp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 11 Jun 2021 16:48:12 -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-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QUK00J7KA4COQI0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Fri, 11 Jun 2021 16:48:12 -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 <0QUK011009TULI00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 11 Jun 2021 16:48:12 -0700 (PDT) X-Va-A: X-Va-T-CD: 7b14d6a7a32af921a367ac8b06702e34 X-Va-E-CD: c087f721d3a96ee8ad637b8e41fc3a56 X-Va-R-CD: b7e321ce675588393d108a7b4559214d X-Va-CD: 0 X-Va-ID: aaa80289-be63-4b3c-bb91-c069388bef8b X-V-A: X-V-T-CD: 7b14d6a7a32af921a367ac8b06702e34 X-V-E-CD: c087f721d3a96ee8ad637b8e41fc3a56 X-V-R-CD: b7e321ce675588393d108a7b4559214d X-V-CD: 0 X-V-ID: 920ec8aa-9b94-4c30-af6e-e71b7195a100 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 <0QUK00G07A4AKQ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 11 Jun 2021 16:48:12 -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: Fri, 11 Jun 2021 16:48:10 -0700 References: <0A1C6D8D-7F91-4038-B340-21104F14D00B@apple.com> <62AF91AB-7008-4DBA-86A6-F24F3F584B16@apple.com> <7E2BF7B0-131E-44EC-92D3-2341CEC9D9BE@apple.com> To: edk2-devel-groups-io , harlydavidsen@gmail.com In-reply-to: Message-id: <38BB1DF8-B608-41AA-81A3-2E68845FF450@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=_2327E3AA-71DF-44EA-A2EE-9CD30D9C1160" --Apple-Mail=_2327E3AA-71DF-44EA-A2EE-9CD30D9C1160 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 11, 2021, at 4:29 PM, Ethin Probst wrot= e: >=20 > Your suggestion of adding 0x240 worked. I'm able to successfully step > through the code now. Thank you! >=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. So t= hat is why you had to add 0x240.=20 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 > 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.de= bug" >>> 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/UsbAudio= .c:72 >>> #1 ProcessModuleEntryPointList (SystemTable=3D0x7f9ee018, >>> ImageHandle=3D0x7e4f7518) at >>> /home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePk= g/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300 >>> #2 _ModuleEntryPoint (ImageHandle=3D0x7e4f7518, SystemTable=3D0x7f9ee= 018) >>> at >>> /home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/A= pplicationEntryPoint.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', NumEndpoi= nts >>> =3D 0 '\000', InterfaceClass =3D 0 '\000', InterfaceSubClass =3D 0 '\0= 00', >>> 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.de= bug >>=20 >> 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 f= or >> the PE/COFF header in memory=E2=80=A6. >>=20 >> So the PE/COFF header starts at 0x7e4b8000 it is likely the text sectio= n >> 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 f= rom >> the load address. >>=20 >> We would need to dump out the UsbAudio.efi file to figure out exactly w= hat >> 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 loo= k. >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>> 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 wh= at >>>>> I do in GDB: >>>>> - Load the EFI application and connect via target remote :1234 >>>>> - type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debu= g >>>>> 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. >>>>> :) >>>>=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. The= re >>>>>> 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= -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 re= ach >>>>>>>>> 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=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 unt= il >>>>>>>>> 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 a= t >>>>>>>>> this >>>>>>>>> point: >>>>>>>>> 1. Either I get the wrong debug information (I get source code b= ut >>>>>>>>> the >>>>>>>>> image isn't loaded anymore), and resetting the system and placin= g 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 ju= st >>>>>>>>> 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 not >>>>>>>>> actually causing anything to happen... You get the idea. >>>>>>>>>=20 >>>>>>>>> So I'm really, really confused on what's going wrong. Do you guy= s >>>>>>>>> have >>>>>>>>> any advice? >>>>>>>>=20 >>>>>>>> Ethin, >>>>>>>>=20 >>>>>>>> Caveat emptor as I use lldb for my daily driver debugger so I mig= ht >>>>>>>> be >>>>>>>> a >>>>>>>> little off on gdb specifics=E2=80=A6. Also my terminology may be = 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 do= n=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 CPU= D >>>>>>>> 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 debugg= ers >>>>>>>> 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 loo= p >>>>>>>> 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 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. >>>>>>>>=20 >>>>>>>> The EFI images are PE/COFF relocatable executables that are linke= d >>>>>>>> around >>>>>>>> zero. They get loaded into memory and relocated, so that is why y= ou >>>>>>>> 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. >>>>>>>>=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 > --=20 > Signed, > Ethin D. Probst >=20 >=20 >=20 --Apple-Mail=_2327E3AA-71DF-44EA-A2EE-9CD30D9C1160 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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

Your suggestion of adding 0x240 worked. I'm able to successfully ste= p
through the code now.= Thank you!


OK t= hat 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. So that i= s why you had to add 0x240. 

Sorry= I had to work backwards from how it works, but maybe that info will be hel= pful for others?

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <<= a href=3D"mailto:afish@apple.com" style=3D"font-family: Helvetica; font-siz= e: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal= ; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0p= x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0= px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class= =3D"">afish@apple.com> wrote:


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

Initial connecti= on and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file= "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug"
at
.= 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=3D0= x7f9ee018,
imageHandle=3D0x7e4f7518) at
/home/e= thin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1  ProcessModuleEntryPointList (SystemTable=3D0x7f9ee018,
ImageHandle=3D0x7e4f7518) at
/home/ethin/source/ed= k/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/Usb= Audio/DEBUG/AutoGen.c:300
#2  _ModuleEntryPoint (ImageHa= ndle=3D0x7e4f7518, SystemTable=3D0x7f9ee018)
at
/home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/Appli= cationEntryPoint.c:59
#3  0x000000007fead316 in ?? ()#4  0x000000007e4f7518 in ?? ()
#5  0x0= 00000007feab5c7 in ?? ()
#6  0x000000007fea3520 in ?? ()=
#7  0x0000000101000000 in ?? ()
#8  = 0x0000000000000030 in ?? ()
#9  0x000000007e4f6018 in ??= ()
#10 0x000000007e60a918 in ?? ()
#11 0x00000= 0000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98= in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0= x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()#18 0x000000007fea3528 in ?? ()
#19 0x00000000000= 00000 in ?? ()
Source-code listing:
1 /** @file
2 =   GCC inline impleme= ntation of BaseLib processor specific functions.
3
4   Copyright (c) 2006 - 2020, I= ntel Corporation. All rights
reserved.<BR>
5   Portions copyright (c) = 2008 - 2009, Apple Inc. All rights
reserved.<BR>
6   SPDX-License-Iden= tifier: BSD-2-Clause-Patent
7
8 **/
9
10<= span class=3D"Apple-tab-span" style=3D"white-space: pre;">
Attempt to use "next":
72 } else if (interfaceDescriptor.Interf= aceClass =3D=3D 0x01 &&
interfaceDescriptor.Interface= SubClass =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 "Ind= ex" in current context.
info local:
UsbIo =3D 0= x0
interfaceDescriptor =3D {Length =3D 0 '\000', DescriptorTy= pe =3D 8 '\b',
InterfaceNumber =3D 1 '\001', 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 21= 18887920
numHandles =3D 264
handles =3D 0x4
status =3D <optimized out>
info symbol 0x000= 7E4B9440:
_ModuleEntryPoint + 576 in section .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 the
PE/C= OFF 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
starts at 0x7e4b= 8240? So try adding 0x240 to the load address on the
add-symb= ol-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 goin= g on. What distro are you on? Do you have the readpe utility? I=E2=80=99m n= ot
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,

An= drew 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.

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


On Jun 11, 20= 21, 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. Here's what
I do in GDB:
- Load the EFI ap= plication and connect via target remote :1234
- type `add-sym= bol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007= E4B8000` and answer yes when it prompts me to do so.
(0x0007E= 4B8000 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 f= rom the following gdb commands?
bt
info localinfo symbol 0x0007E4B9440

What ex= actly is gdb showing you?

Thanks,

Andrew Fish


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


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@gmail.com=
<ma= ilto:harlydavidsen@gmail.com>>
wrote:

Hi Andrew,
How do you debug the EFI binary wi= th LLDB? Can LLDB use GDB stubs or
does that work differently= ?


Ethin,

Lldb is the command line debugger that comes with Xco= de on Mac. There
is
no
gdb with X= code, so I have to use lldb for my day job.

Ll= db can speak the gdb remote serial protocol: lldb -o =E2=80=9Cgdb-remote9000=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.co= m>
<m= ailto:afish@apple.com <mailto:afish@apple.com>>
<= mailto:afish@apple.com <mailto:afish@apple.com<= /a>>
<mai= lto:afish@apple.com &= lt;mailto:afish@apple.com= >>>> wrote:
=

On Jun 1= 1, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <= mailto:harlydavidsen@gmail.com>>>
wrote:

Hey all,

So Leif and I h= ave discussed this at length but I thought I'd reach
out to a= ll of you for more help.

I'm having a lot of t= rouble debugging my UEFI app. Here's how I do
things:

- I load the app using 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>>) 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.f= d
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -us= b
-device
qemu-xhci -device usb-audio,audiodev= =3Daudio -audiodev alsa,id=3Daudio
-s
-debugco= n stdio -global isa-debugcon.iobase=3D0x402
- I connect to th= e 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 butthe
image isn't loaded anymore), and resetting t= he system and placing a
breakpoint (either software or hardwa= re) has no effect; or
2. If I use CpuBreakpoint(), the firmwa= re gives me the registers
and
the image base an= d 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 <a= rtificial>", I can't jump
into
my code witho= ut 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=E2=80=A6. Also my terminology may be ll= db
centric.

Easy one 1st. When y= ou run on top of a debugger using
CpuBreakpoint()
works
great as the debugger hides its self from you. On x8= 6
CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don= =E2=80=99t
have
a
debugger hooke= d 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 i= n the wrong driver. A lot of times for hardware debuggers
it<= br class=3D"">works better to use CpuDeadLoop(). The gdb-remote stub from Q= EMU
acts
a
lot
more= like a JTAG hardware debugger than a pure software debugger.
Also
note
that CpuDeadLoop() is an infinite lo= op, so you can modify the loop
variable
with th= e 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 thesymbols.
The
reason for me suggesti= ng this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will c= reate a target
for
a
stock x86-64= image. When you connect to the QEMU gdb-remote there is
ahandshake that describes the target and what registers are
available.
I
seem
to re= member QEMU exports some of the system registers, like the
co= ntrol
registers, so it is an extended version of the x86-64 t= arget. So
this
changing the target definition m= ight 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
to
sp= ecify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) buil= d 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 lik= e, obviously you can read any
variables. This can be useful i= f you get the unhandled exception and
it
prints= out the load address and offset (you can use the offset
dire= ctly).
It
is also a good way to debug why your = symbols are not quite loaded at
the
correct add= ress, as you can see what bytes/instructions should be at
agiven
address.

Than= ks,

Andrew Fish

<= blockquote type=3D"cite" class=3D"">
--
Signed,=
Ethin D. Probst


=





--
Si= gned,
Ethin D. Probst







--
Signed,
Eth= in D. Probst







--
Signed,
Ethin D. Probst




-- 
Signed,
Ethin D. Probst



--Apple-Mail=_2327E3AA-71DF-44EA-A2EE-9CD30D9C1160--