Hi Marvin, Yes. This is intentional. If MODULE_UNLOAD is not provided, then the module can never be unloaded. The LoadImage() services initializes the Unload field to NULL, and if UnloadImage() is called and the Unload field is NULL, it returns an EFI_UNSUPPORTED.
I do not think the case you describer is possible. If ProcessModuleUnloadList() returns an error, then ProcessLibraryDestructorList()is not called. Since the module is not unloaded, it is still in allocated memory. How would the protocol point to a freed buffer? Mike -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Marvin H?user Sent: Wednesday, June 14, 2017 6:41 PM To: edk2-devel@lists.01.org Subject: [edk2] Regarding UefiDriverEntryPoint unload handler Dear developers, While performing some research tasks, I noticed that when UefiDriverEntryPoint's _gDriverUnloadImageCount is 0 (only MODULE_UNLOAD entries are count, DESTRUCTOR as they are used with libraries are not, as far as I can see), EFI_LOADED_IMAGE_PROTOCOL.Unload is not set, even if libraries with destructors are included by the built module. Is this intentional, so, is a module without a MODULE_UNLOAD property in its build file considered a module that does not support being unloaded? If so, why is EFI_LOADED_IMAGE_PROTOCOL.Unload not set to a dummy that returns an EFI error code? For example, DxeDebugPrintErrorLevelLib installs a protocol interface in its CONSTRUCTOR function. When this library is included in a module without a MODULE_UNLOAD property and that module is unloaded, the DxeDebugPrintErrorLevelLib DESTRUCTOR function, which uninstalls the interface, is never called and hence the interface remains in the protocol database, despite it pointing to a memory location that is now free. If it is called, the behavior is obviously undefined. Did I understand something incorrectly, are these modules not supposed to be unloadable or is this a bug? Thank you, Marvin. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
