Re: EmulatorPkg and the state of DlLoadImage()

Andrew Fish

On Jul 30, 2021, at 3:37 AM, Marvin Häuser <mhaeuser@...> wrote:

Good day everyone,

I'm currently refining the port of EmulatorPkg to my new PE/COFF loader library instance.
In the process, I found the function DlOpenImage() [1], which loads UEFI Images via the OS loader to utilise its symbol loading capability. Theoretically, this should e.g. allow arbitrary debuggers using the OS APIs to symbolise the backtrace.

macOS: The function seems to be unused entirely. [2]

Linux: On my system running Fedora 34, the function neither works out-of-the-box, nor after significant time of trying to fix it. The first issue is that it only proceeds if the Image has a PDB path with ".pdb" extension [3], while the GCC5 toolchain generates Images with ".dll" files for PDB paths (see errors below). Once this is resolved, there is an error message indicating insufficient Image section alignment:

[...]/Build/EmulatorX64/DEBUG_GCC5/X64/MdeModulePkg/Universal/EbcDxe/EbcDxe/DEBUG/EbcDxe.dll: ELF load command alignment not page-aligned

The requiring *.pdb seems like something that rotted out and could be fixed. 

Resolving this yields an error that executable files cannot be loaded dynamically:

[...]/Build/EmulatorX64/DEBUG_GCC5/X64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll: cannot dynamically load executable

With my very limited knowledge about Linux and ELF I tried the naive approach of building the Images as shared (hoping it would be similar to DLLs, which are built on Windows), but this just silently crashes.

This code is very very old. Notice the comment about gdb predates gdb Python support [1].

What happens if you comment out the DlLoadImage path? There seems to be some gdb scripts? The macOS path sets breakpoints on SecGdbScriptBreak() in an lldb script and loads symbols via that path. That his probably the best path forward for gdb too? 

It looks like if you ` run` you should launch the emulator under gdb and source the symbol loading file.
EmulatorPkg/  /usr/bin/gdb $BUILD_ROOT_ARCH/Host -q -cd=$BUILD_ROOT_ARCH -x $WORKSPACE/EmulatorPkg/Unix/

If you comment out the dlopen() path does it start working? Looks like breaking in with gdb should get symbols loaded? 

So my questions are:
1) Does this code currently work for anyone?
2) Does anyone use a debugging setup that is incompatible with Images loaded by EDK II rather than the OS?

Not a 100% sure what you are asking? In a lot of cases you are debugging what is compatible with the OS? For example on macOS we build a mach-O and convert that to PE/COFF. We point the PDB entry at the mach-O file and that is what the debugger sees. As long as the PE/COFF lines up with the mach-O it does not really matter, as at the end of the day the debugger is just processing the dwarf debug info associated with addresses in system memory. 

3) Are the issues above known and planned to be fixed?

Not likely please file a BZ. 

Note I’m working on getting a generic gdb debugging script into the edk2 [2] and that should also work with the Emulator. I think you could replace the ` -x $WORKSPACE/EmulatorPkg/Unix/` with `-ex’. There is not a break hook in those scripts so you would have to run the `efi` command the 1st time you attach to load symbols. The script works on stock EFI so it does not depend on any of the hooks in the EmulatorPkg to work. 

Thank you for your time!

Best regards,





Andrew Fish

Join to automatically receive all group messages.