From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web10.6988.1593257880159661077 for ; Sat, 27 Jun 2020 04:38:00 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 11798D6E; Sat, 27 Jun 2020 04:37:59 -0700 (PDT) Received: from [192.168.1.69] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6C1763F6CF; Sat, 27 Jun 2020 04:37:57 -0700 (PDT) Subject: Re: [PATCH v3 08/15] MdeModulePkg: Fix constructor invocation ordering To: Laszlo Ersek , Sami Mujawar , devel@edk2.groups.io Cc: leif@nuviainc.com, jian.j.wang@intel.com, hao.a.wu@intel.com, Alexandru.Elisei@arm.com, Andre.Przywara@arm.com, Matteo.Carlini@arm.com, Laura.Moretta@arm.com, nd@arm.com References: <20200624133458.61920-1-sami.mujawar@arm.com> <20200624133458.61920-9-sami.mujawar@arm.com> <333ca5d4-2959-4ebe-54df-c0f36f60f8b0@arm.com> <9a142911-8c47-7139-45b8-1429d5aa16c7@redhat.com> From: "Ard Biesheuvel" Message-ID: <858cae73-d833-3aa7-3361-86abe20b98d2@arm.com> Date: Sat, 27 Jun 2020 13:37:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <9a142911-8c47-7139-45b8-1429d5aa16c7@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/26/20 3:22 PM, Laszlo Ersek wrote: > On 06/25/20 15:51, Ard Biesheuvel wrote: >> On 6/24/20 3:34 PM, Sami Mujawar wrote: >>> The BaseSerialPortLib16550 library does not implement >>> a constructor. This prevents the correct constructor >>> invocation order for dependent libraries. >>> e.g. A PlatformHookLib (for the Serial Port) may have >>> a dependency on retrieving data from a Hob. A Hob >>> library implementation may configure its initial state >>> in the HobLib constructor. Since BaseSerialPortLib16550 >>> does not implement a constructor, the Basetools do not >>> resolve the correct order for constructor invocation. >>> >>> To fix this, add an empty constructor to the serial port >>> library BaseSerialPortLib16550. >>> >>> Signed-off-by: Sami Mujawar >> >> Acked-by: Ard Biesheuvel >> >> Note to maintainers: >> this works around a long standing BaseTools bug where constructor >> dependencies do not propagate through a library that lacks a construct= or. >> >> For instance, in the following case >> >> =C2=A0 LibA depends on LibB depends on LibC >> >> the constructors are *only* guaranteed to be invoked in the correct >> order (LibC, then LibB, then LibA) if LibB has a constructor in the >> first place, otherwise, the remaining constructors for LibA and LibC >> could be emitted in any order. >=20 > By now I've flipped my "mental default" to "use a constructor *unless* > counter-indicated by something"... >=20 > If we get a cycle due to always using constructors, the tools at least > complain (and we know something's fishy). With the opposite default, I > simply cannot guarantee that my new library instance LibB will *never* > break an eventual LibA -> LibB -> LibC constructor dependency chain. >=20 > In my new lib instance, I'm of course aware of the LibB -> LibC > dependency, but I can't tell anything about a future LibA -> LibB > dependency. :( >=20 > So I guess it's prudent to always add a constructor, even if it's empty= . >=20 Indeed. I guess the issue arises when LibA's constructor calls a function=20 exposed by LibB. The fact that we care about constructor ordering at all=20 implies that constructor implementations are permitted to depend on=20 library routines, and so this should be perfectly fine. So it is really=20 up to the BaseTools to ensure that calling LibB is safe at this point,=20 which implies that the must constructors have been called for anything=20 that LibB depends on. So I don't see how this is not a bug - ordering is either enforced or it=20 isn't, but the dependency graph should not omit libraries without=20 constructors.