On Wed, 1 Apr 2020 at 10:37, Laszlo Ersek <[email protected]> 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. > > ArmVirtPkg/Library/ArmVirtDxeHobLib/HobLib.c > > 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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#56824): https://edk2.groups.io/g/devel/message/56824 Mute This Topic: https://groups.io/mt/72673992/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
