Nt32 emulator: Source level debugging

["Peter Kirmeier" <topeterk@freenet.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