From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) (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 08EB621A16E28 for ; Thu, 11 May 2017 10:23:09 -0700 (PDT) Received: from [195.4.92.141] (helo=mjail1.freenet.de) by mout0.freenet.de with esmtpa (ID topeterk@freenet.de) (port 25) (Exim 4.85 #1) id 1d8rnu-0004ZJ-04 for edk2-devel@ml01.01.org; Thu, 11 May 2017 19:23:06 +0200 Received: from localhost ([::1]:46706 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID topeterk@freenet.de) (Exim 4.85 #1) id 1d8rnt-00034G-P0 for edk2-devel@ml01.01.org; Thu, 11 May 2017 19:23:05 +0200 Received: from mx14.freenet.de ([195.4.92.24]:47288) by mjail1.freenet.de with esmtpa (ID topeterk@freenet.de) (Exim 4.85 #1) id 1d8rlU-0002Ef-BY for edk2-devel@ml01.01.org; Thu, 11 May 2017 19:20:36 +0200 Received: from dslb-092-074-148-027.092.074.pools.vodafone-ip.de ([92.74.148.27]:4638 helo=Gunrider) by mx14.freenet.de with esmtpsa (ID topeterk@freenet.de) (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (port 587) (Exim 4.85 #1) id 1d8rlT-0007X3-Rs for edk2-devel@ml01.01.org; Thu, 11 May 2017 19:20:36 +0200 From: "Peter Kirmeier" To: "'edk2-devel@lists.01.org'" Date: Thu, 11 May 2017 19:20:35 +0200 Message-ID: <000601d2ca7a$e7924770$b6b6d650$@de> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdLKeucDKGe7X60eT96nrBb+q313cw== X-Originated-At: 92.74.148.27!4638 Subject: Nt32 emulator: Source level debugging X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 17:23:09 -0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: de Hi all, I encountered an issue again which may be open since around 4 years (see "Source-level-debugging (NT32 + MS Visual Studio 2010)". So if still anyone has issues with debugging modules in NT32Pkg because of no/wrong symbols loaded then this may help you out: In my case the issue was caused by the missing exported DLL symbols. For me it looks like, when the "export" section is kind of empty, then Visual Studio have issues finding and loading the PDB files properly. To avoid this the Nt32Pkg.dsc has a workaround in its "BuildOptions" section: [BuildOptions] DEBUG_*_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000 /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE NOOPT_*_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x10000 /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE RELEASE_*_*_DLINK_FLAGS = /ALIGN:4096 /FILEALIGN:4096 This creates an entry in the "export" section for the symbol "InitializeDriver" which is pointing to the module's entry point. It also comes with some addressing tweaks like alignment and base address. So building the ShellPkg.dsc will build everything without the "InitializeDriver" and therefore the SecMain code will tell you that by printing "WARNING: No source level debug" when the shell/driver/application gets loaded. Simply copy the "BuildOptions" section from Nt32Pkg.dsc into your DSC file and you should be good to go. For example, adding it to ShellPkg.dsc will build the Shell with all the needed symbols. By the way: Don't forget to copy your built Shell.efi into the ShellBinPkg before generating the Nt32Pkg! Otherwise your brand new Shell is not built into the FV which is used by SecMain for its primary boot option. No answer is needed, I just want to tell the world and help anyone that may struggled the same. Best Regards, Peter