[if gte mso 9]>

[edk2] ConstructorList errors

Subject: [edk2] ConstructorList errors

From: Tim Lewis <tim.lewis@insyde.com>

To: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>

Date: 2012-10-13 09:06:44

The current AutoGen.c creates a function ProcessLibraryConstructorList() which is called from the standard entry point for UEFI Shell applications. We recently ran into a case where shell applications fail because of the lack of error handling in this function. Currently, this function calls all of the functions declared with CONSTRUCTOR in their INF. For example:

 

  Status = __wchar_construct (ImageHandle, SystemTable);

  ASSERT_EFI_ERROR (Status);

 

  Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);

  ASSERT_EFI_ERROR (Status);

 

  Status = __Cons_construct (ImageHandle, SystemTable);

  ASSERT_EFI_ERROR (Status);

 

  Status = UefiRuntimeServicesTableLibConstructor (ImageHandle, SystemTable);

  ASSERT_EFI_ERROR (Status);

 

The problem is that this function is a VOID. So, even if these constructors fail, there is no way to terminate the application.

 

We found this issue where a CONSTRUCTOR function looked for a protocol and returned an error if it failed. We always use the release version. It fails in mysterious ways because the constructor function succeeds and then launched the declared entry point, which tries to use a library function that uses the protocol, which is some garbage value and goes off in the weeds.

 

Instead, this function should return a status code and _ModuleEntryPoint (from UefiApplicationEntryPoint, etc.) should return EFI_LOAD_ERROR so that the application will fail.

 

This would prevent undefined behavior when the protocol does not exist on a platform. Otherwise the application (or the library) must still check for the protocol pointer validity, which defeats the purpose of using a CONSTRUCTOR.

 

Tim