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.web11.7592.1593177763243663924 for ; Fri, 26 Jun 2020 06:22:44 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gK32Lmh4; 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=1593177762; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cejh5YAZ/mWi0kgaYLz65ess2cZ9O3lMT43UGqHOb2o=; b=gK32Lmh42R+aWx/h0g7UWdcvp3tcoEjrXkalAZqtZJMdFKv1UCS29a4V9tcjQ0l3uTSWQM HZadN5jvC4qcgsAZRBumjHFPkAVc8/D/tYqDYQ36UEy04ofJp7w/Zw0yrFQdUFz/trZI3k RPE6wza93pj559Ax6f5NoqBzmFiO2Ug= 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-225-AP6Q96nWMoO_UNpG3EPKMA-1; Fri, 26 Jun 2020 09:22:40 -0400 X-MC-Unique: AP6Q96nWMoO_UNpG3EPKMA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 892F518FF663; Fri, 26 Jun 2020 13:22:38 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-178.ams2.redhat.com [10.36.112.178]) by smtp.corp.redhat.com (Postfix) with ESMTP id 422311001B0B; Fri, 26 Jun 2020 13:22:35 +0000 (UTC) Subject: Re: [PATCH v3 08/15] MdeModulePkg: Fix constructor invocation ordering To: Ard Biesheuvel , 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> From: "Laszlo Ersek" Message-ID: <9a142911-8c47-7139-45b8-1429d5aa16c7@redhat.com> Date: Fri, 26 Jun 2020 15:22:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <333ca5d4-2959-4ebe-54df-c0f36f60f8b0@arm.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 constructor. > > For instance, in the following case > >   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. By now I've flipped my "mental default" to "use a constructor *unless* counter-indicated by something"... 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. 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. :( So I guess it's prudent to always add a constructor, even if it's empty. Laszlo