From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by mx.groups.io with SMTP id smtpd.web12.2254.1585731068266154466 for ; Wed, 01 Apr 2020 01:51:08 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=H7Kuuz9T; spf=pass (domain: linaro.org, ip: 209.85.221.65, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wr1-f65.google.com with SMTP id h15so29495793wrx.9 for ; Wed, 01 Apr 2020 01:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4sZCM/pugO7cEqkbkOIeEtYy2eP4Nj2T/LzdPh51y+E=; b=H7Kuuz9Tif0L3kkJoo0wkaGaSHr8SdG5SOi9GNTSZ7P1OoBPpQmfTFGZP+fPcYS+Mm f91Qsw7VR+bv/tt8C7zSVNYycfa3gno0TfFNeuELWRxBMX4SBYCiWp/O94VDpbqg42Cl LtS3ZaqR6dh7D7sxY60XBd/sKpvUHJmn6bkiT/1o+xTEOUVGd5leQW01HC2uVnhl06J9 bJ+JWVfw1+v5/V9Yf24IfgOqFnGq9HfuMRmtjTMnxouxAKXyAw/U/7hfwr0zGvSnYSLX GREaYlyH//t9Y7XaiYv0WUqpikbl8vBlOAiyzZvIZdXWSXL+RA+8Mss58ZAnPKl2/uDX Dfpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4sZCM/pugO7cEqkbkOIeEtYy2eP4Nj2T/LzdPh51y+E=; b=fXpYHffPPxsN3t0C07Qh23EG3F19H9HAaSbJZLrYEl/IgVCkEQZ7hA/lt6PY2955hy j4h8ED/XdusNCxDsKbEcjr7nby+NI8MJwM36PNP+64sTDVXJwpK/t4vCGV9g7s6fYard zME05xnHeKyI3byevv6hk4+7nf0qTIaXsflw0fcChy2sI8CD9hGGrr6hMh+BNez4Frmw h0SI95H9tSxHigTfab1g14FMHE2VD9J1CxV7VyPb6A4hdZM6CllG6A6OcDWJVGAkGY6i jI2NzmG8dOTk85dnSc44HICUPqC9+xrr5NAh09tqYw4lZT5cWJoYx3qrikT2gElNh4qG XANQ== X-Gm-Message-State: ANhLgQ1PN+UOANzKXctXdvJkqTYFUpSlAmMy0UJIudQhI6Pn01bcapWT nel31eNA3fUZjsceUett0y6nK7Qf04bgSyvM7HAqrA== X-Google-Smtp-Source: ADFU+vuWdG39o2Pdw8Dq2QsDfXzmrF3S3ZA0Ot345vAybH4cx1KhUsv4OeE4mTyaLju8pFGMXY6Y8PAD7dFuWF3ED10= X-Received: by 2002:adf:afdb:: with SMTP id y27mr25070626wrd.208.1585731066661; Wed, 01 Apr 2020 01:51:06 -0700 (PDT) MIME-Version: 1.0 References: <20200331110452.51992-1-liran.alon@oracle.com> <22866.1585670000047029434@groups.io> <4b90b41a-2cf1-8b6e-6619-1c652820265e@redhat.com> <5221e324-9f86-24b4-56a0-301a948151f8@oracle.com> <30a57406-0c09-043f-6b19-7e6e94afcb44@oracle.com> <56339bff-ae66-2902-eb7b-3426a6b2cb7a@redhat.com> In-Reply-To: <56339bff-ae66-2902-eb7b-3426a6b2cb7a@redhat.com> From: "Ard Biesheuvel" Date: Wed, 1 Apr 2020 10:50:54 +0200 Message-ID: Subject: Re: [edk2-devel] [PATCH] OvmfPkg/PvScsiDxe: Fix VS2019 build error because of implicit cast To: Laszlo Ersek Cc: Liran Alon , edk2-devel-groups-io , Sean Brogan Content-Type: text/plain; charset="UTF-8" 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. > > 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.