public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: Rebecca Cran <rebecca@bsdio.com>,
	devel@edk2.groups.io, Anthony Perard <anthony.perard@citrix.com>,
	Julien Grall <julien@xen.org>,
	Ard Biesheuvel <ard.biesheuvel@arm.com>
Subject: Re: OvmfPkg XenPkg: X64 DEBUG GCC5 -DDEBUG_ON_SERIAL_PORT=TRUE build is broken
Date: Wed, 15 Apr 2020 16:04:35 +0200	[thread overview]
Message-ID: <fd2eb882-087b-cbca-5288-805c9d368ca8@redhat.com> (raw)
In-Reply-To: <e1f7e62c-adb4-eace-3828-7d73ae59ecd4@bsdio.com>

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 {
> +    <LibraryClasses>
> +      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


  reply	other threads:[~2020-04-15 14:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14 18:01 OvmfPkg XenPkg: X64 DEBUG GCC5 -DDEBUG_ON_SERIAL_PORT=TRUE build is broken Rebecca Cran
2020-04-15 14:04 ` Laszlo Ersek [this message]
2020-04-15 14:20   ` Rebecca Cran
2020-04-16 16:52     ` [edk2-devel] " Laszlo Ersek
2020-04-20 12:38   ` Anthony PERARD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fd2eb882-087b-cbca-5288-805c9d368ca8@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox