From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web10.14927.1586959485398000931 for ; Wed, 15 Apr 2020 07:04:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WQTcmv5b; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586959484; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RxkKBLRubfFD2EmQCQXHcbSHuQ6lxpYUMXD+lJupSso=; b=WQTcmv5bHr630XeD98iXoyljAVv6ZsG1HJ4oL1IPPP4H45hpu9CofGV4jMTZjMaG/UDTQ8 Q6/tffTgKLWKTPcaeT/IuuK1beeckWtO1srGONexAHvljf8K+koWWGIMp3i17/RhXHyXd4 An0QAao3Iw7uxitrcNd3zVviGQFwVwc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-289-cO4Axm-UO1eBtYvvl7ujJA-1; Wed, 15 Apr 2020 10:04:39 -0400 X-MC-Unique: cO4Axm-UO1eBtYvvl7ujJA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CEA13107ACC4; Wed, 15 Apr 2020 14:04:37 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-155.ams2.redhat.com [10.36.112.155]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4D2E85D9E2; Wed, 15 Apr 2020 14:04:36 +0000 (UTC) Subject: Re: OvmfPkg XenPkg: X64 DEBUG GCC5 -DDEBUG_ON_SERIAL_PORT=TRUE build is broken To: Rebecca Cran , devel@edk2.groups.io, Anthony Perard , Julien Grall , Ard Biesheuvel References: From: "Laszlo Ersek" Message-ID: Date: Wed, 15 Apr 2020 16:04:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 04/14/20 20:01, Rebecca Cran wrote: > I was trying to build OvmfPkg/XenPkg -a X64 -t GCC5 -b DEBUG > -DDEBUG_ON_SERIAL_PORT=TRUE, but the build fails. Both plain DEBUG and > RELEASE builds without trying to put the debug output on the serial > port work. > > > [bcran@smic ~/src/tmp/edk2]$ build -p OvmfPkg/OvmfXen.dsc -a X64 -t > GCC5 -b DEBUG -DDEBUG_ON_SERIAL_PORT=TRUE > Build environment: FreeBSD-13.0-CURRENT-amd64-64bit-ELF > Build start time: 11:59:24, Apr.14 2020 > > WORKSPACE = /home/bcran/src/tmp/edk2 > EDK_TOOLS_PATH = /home/bcran/src/tmp/edk2/BaseTools > CONF_PATH = /home/bcran/src/tmp/edk2/Conf > PYTHON_COMMAND = /usr/local/bin/python3 > > > Processing meta-data . > Architecture(s) = X64 > Build target = DEBUG > Toolchain = GCC5 > > Active Platform = /home/bcran/src/tmp/edk2/OvmfPkg/OvmfXen.dsc > . > > build.py... > /home/bcran/src/tmp/edk2/OvmfPkg/OvmfXen.dsc(...): error F002: Library > [/home/bcran/src/tmp/edk2/MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf] > with constructors has a cycle > consumed by > /home/bcran/src/tmp/edk2/MdePkg/Library/UefiLib/UefiLib.inf > consumed by > /home/bcran/src/tmp/edk2/MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLibDevicePathProtocol.inf From commit 05480e2fd4ff ("OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn", 2019-08-21), we have: > diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc > index 54ac910d8eed..e719a168f81e 100644 > --- a/OvmfPkg/OvmfXen.dsc > +++ b/OvmfPkg/OvmfXen.dsc > @@ -586,6 +586,10 @@ [Components] > OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf > OvmfPkg/XenBusDxe/XenBusDxe.inf > OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf > + MdeModulePkg/Universal/SerialDxe/SerialDxe.inf { > + > + SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf > + } > MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf > MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf > MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf If you run the "build" command with the "-v" option added, the last part (just preceding the error message above) is: > Library instances of module [MdeModulePkg/Universal/SerialDxe/SerialDxe.inf] [X64]: > UefiDriverEntryPoint : MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf > UefiBootServicesTableLib : MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf > DebugLib : MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf > PcdLib : MdePkg/Library/DxePcdLib/DxePcdLib.inf > SerialPortLib : OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf > BaseLib : MdePkg/Library/BaseLib/BaseLib.inf > XenHypercallLib : OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf > HobLib : MdePkg/Library/DxeHobLib/DxeHobLib.inf > BaseMemoryLib : MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf > UefiLib : MdePkg/Library/UefiLib/UefiLib.inf > PrintLib : MdePkg/Library/BasePrintLib/BasePrintLib.inf > MemoryAllocationLib : MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf > DevicePathLib : MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLibDevicePathProtocol.inf > UefiRuntimeServicesTableLib : MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf > DebugPrintErrorLevelLib : MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf The dependency loop is formed by: DebugLib : BaseDebugLibSerialPort -> SerialPortLib : XenConsoleSerialPortLib -> XenHypercallLib : XenHypercallLib -> DebugLib where all the library instances BaseDebugLibSerialPort, XenConsoleSerialPortLib, XenHypercallLib have constructors. Note that XenConsoleSerialPortLib *itself* is careful to avoid a DebugLib dependency; from "XenConsoleSerialPortLib.c": > // > // We can't use DebugLib due to a constructor dependency cycle between DebugLib > // and ourselves. > // > #define ASSERT(Expression) \ > do { \ > if (!(Expression)) { \ > CpuDeadLoop (); \ > } \ > } while (FALSE) However, XenConsoleSerialPortLib still inherits a DebugLib dependency through XenHypercallLib -- but only on IA32/X64, not on ARM/AARCH64! See "XenHypercallLib.inf": > [LibraryClasses.IA32, LibraryClasses.X64] > BaseLib > HobLib > DebugLib There is no issue without specifying DEBUG_ON_SERIAL_PORT, because OvmfXen resolves DebugLib to PlatformDebugLibIoPort then, which does not depend on SerialPortLib (thus the cycle is severed). Now, I think there may not be a simple solution for this, because, as the message on commit 05480e2fd4ff says, "On a Xen PVH guest, none of the existing serial or console interface works". So even if we eliminated the constructor cycle for this module -- i.e., SerialDxe -- somehow [1], the larger DEBUG_ON_SERIAL_PORT feature might not be feasible for *some* module types in OvmfXen. Because, XenConsoleSerialPortLib ultimately depends on hypercalls, and I'm unsure if those could be used as early as in SEC / PEI. [1] For breaking up just this one constructor cycle, I guess we could remove the DebugLib dependency from XenHypercallLib even on IA32/X64. In other words, I'm not sure if you could send any DEBUG messages *at all* to the Xen serial port as early as in SEC or PEI. Meaning that even if DEBUG_ON_SERIAL_PORT didn't break the build, it still wouldn't (comprehensively) do what its name says. I figure you attempted the DEBUG_ON_SERIAL_PORT build because without it you get no debug output at all (due to the default PlatformDebugLibIoPort resolution, which produces no logs on Xen). For a start, I would recommend removing DEBUG_ON_SERIAL_PORT altogether from OvmfXen (to decrease confusion and to eliminate the build breakage), and then filing a feature request in the TianoCore bugzilla for "some" kind of debug logging in OvmfXen, if the latter is possible. Thanks Laszlo