From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (no SPF record) identity=mailfrom; client-ip=128.130.2.109; helo=mr.tuwien.ac.at; envelope-from=johannes.swoboda@student.tuwien.ac.at; receiver=edk2-devel@lists.01.org Received: from mr.tuwien.ac.at (mr1.kom.tuwien.ac.at [128.130.2.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6F6B02279CF06 for ; Fri, 20 Apr 2018 09:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at vc2.kom.tuwien.ac.at Received: from mail.student.tuwien.ac.at (mail1.student.tuwien.ac.at [193.170.73.221]) by mr.tuwien.ac.at (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id w3KGcdOQ003389; Fri, 20 Apr 2018 18:38:40 +0200 MIME-Version: 1.0 Date: Fri, 20 Apr 2018 18:38:39 +0200 From: Johannes Swoboda To: "Palmer, Thomas" , Laszlo Ersek Cc: Rebecca Cran , Michael Kinney , edk2-devel@lists.01.org, clemens.hlauschek@inso.tuwien.ac.at In-Reply-To: References: <12fe2332-c864-60e1-4f12-280e9939449f@redhat.com> <81abcc10-1c8c-1012-7c08-b9cd24efa85a@bluestop.org> <020ac090-c1e9-0c73-a484-e785c1b7e423@redhat.com> Message-ID: X-Sender: johannes.swoboda@student.tuwien.ac.at User-Agent: Roundcube Webmail/1.1.10 Subject: Re: gdb reload-uefi missing EFI_SYSTEM_TABLE_POINTER [was: Source code debugging of OVMF] X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 16:38:56 -0000 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hello again, Thank you again for taking the time to help me with this. On 2018-04-20 17:58, Palmer, Thomas wrote: > Also, did you start qemu with the "-s" option before you started gdb? Unfortunately, I start qemu with -s -S; then, I attach gdb. I know the attaching works because I gdb accepts the continue command which instructs qemu to begin execution of the virtual machine. The source [...]/gdb_uefi.py command seems to work find, but reload-efi -o [...]/DEBUG/GdbSyms.dll throws the error "No type named EFI_SYSTEM_TABLE_POINTER". Here is my .gdbinit set height 0 set architecture i386:x86-64:intel target remote localhost:1234 source ~/18S/bakk/work/debug_w_andreiw/edk2/DebugPkg/Scripts/gdb_uefi.py reload-uefi -o ~/18S/bakk/work/debug_w_andreiw/edk2/Build/OvmfX64/DEBUG_GCC5/X64/DebugPkg/GdbSyms/GdbSyms/DEBUG/GdbSyms.dll which is executed on gdb startup: [johannes@johannes-laptop efi_app_only]$ gdb [...] The target architecture is assumed to be i386:x86-64:intel warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x000000000000fff0 in ?? () Python Exception No type named EFI_SYSTEM_TABLE_POINTER.: .gdbinit:5: Error in sourced command file: Error occurred in Python command: No type named EFI_SYSTEM_TABLE_POINTER. (gdb) Do you have any other suggestions? Kind regards, Johannes > -----Original Message----- > From: Laszlo Ersek [mailto:lersek@redhat.com] > On 04/20/18 16:54, Johannes Swoboda wrote: >> >> You advised me to use the scripts from [1]. >> I did so following this guide [2] (thank you also for putting it back >> up!), with the minor adaptions that I made the script >> python3-compatible[3], and applied the patches mentioned in [2] >> manually. I assume they failed because they could only be applied to >> older versions of the files to be patched. >> >> In particular, I added the line DebugPkg/GdbSyms/GdbSyms.inf right >> below line OvmfPkg/PlatformDxe/Platform.inf in line 830 of the >> vUDK2018 release. That makes sense, right? > > You can add GdbSyms.inf anywhere near the other DXE phase modules. > Just make sure that you patch the DSC file(s) that you build and run > afterwards. (I.e., avoid the case where you patch e.g. the X64 DSC but > then build & boot the IA32 binary.) Allright, I should be safe there. >> However I ran into a problem when executing >>> (gdb) reload-uefi -o >>> ./Build/OvmfX64/DEBUG_GCC5/X64/DebugPkg/GdbSyms/GdbSyms/DEBUG/GdbSyms >>> .dll >> >> gdb complained: >>> Python Exception No type named >>> EFI_SYSTEM_TABLE_POINTER.: >>> Error occurred in Python command: No type named >>> EFI_SYSTEM_TABLE_POINTER. >> >> The EFI_SYSTEM_TABLE_POINTER is defined in >> [WORKSPACE]/MdeModulePkg/Core/Dxe/Misc/DebugImageInfo.c, so I'm >> guessing I lack that file respectively its corresponding module. > > This command will only work after you attach gdb to qemu. In general, > python extensions for gdb can only look up non-standard typenames etc. > if gdb is connected to a live image that uses those types.