Re: [PATCH] OvmfPkg/PvScsiDxe: Fix VS2019 build error because of implicit cast

Ard Biesheuvel

On Wed, 1 Apr 2020 at 10:37, Laszlo Ersek <> wrote:

On 04/01/20 00:17, Liran Alon wrote:

I would also mention that there are some bizzare code in EDK2 that
defines it's own ASSERT() macro that just does CpuDeadLoop(). E.g.
This is a very special case.

Please see the justification in commit ad90df8ac018
("ArmPlatformPkg/ArmVirtualizationPkg: Add private HobLib implementation
for DXE phase", 2014-09-18).

The stock HobLib instance depends on DebugLib, for using the normal
ASSERT() macro.

Furthermore, the stock serial-based DebugLib instance depends on
SerialPortLib, for printing messages.

That produces a HobLib -> DebugLib -> SerialPortLib dependency chain.

But, in case of this particular platform, our SerialPortLib instance
depends on HobLib, for retrieving the particulars of the serial port.
This creates a dependency cycle:

HobLib -> DebugLib -> SerialPortLib -> HobLib

which makes the platform un-buildable.

We had to break the dependency cycle somewhere, and the best (or maybe
only -- I don't recall exactly anymore) link to break was the HobLib ->
DebugLib dependency. We introduced our own HobLib instance, which (IIRC)
was almost identical to the stock one, except that its (only) DebugLib
dependency, namely the ASSERT(), was reimplemented with a plain
CpuDeadLoop(). And so the dependency chain ended up as:

DebugLib -> SerialPortLib -> HobLib

Not circular any more.

and OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c)
Very similar same case; here we even have a comment:

// We can't use DebugLib due to a constructor dependency cycle between DebugLib
// and ourselves.

The BaseDebugLibSerialPort instance depends on SerialPortLib, so a
SerialPortLib instance cannot "depend back" on DebugLib, in combination
with BaseDebugLibSerialPort.
There's an additional problem in EDK2 that we never fixed, which is
the fact that constructor dependencies are not transitive across
library implementations that don't have a constructor themselves. For
instance, in the following case

LibA (+)
depends on
LibB (-)
depends on
LibC (+)

where (+) means 'has constructor' and (-) means 'has no constructor',
the EDK2 build tools may emit the LibA and LibC constructor
invocations in any order. However, as soon as you try to fix this, we
end up with circular dependencies all over the place, and none of the
platforms can be built anymore.

Join to automatically receive all group messages.