Re: [edk2-devel] MdeModulePkg build fails for AARCH64 on Ubuntu 22.04

["Ard Biesheuvel" <ardb@kernel.org>]

On Mon, 22 Aug 2022 at 11:11, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> (cc Bob)
>
> NOTE this affects the stable tag - please see below
>
>
> On Sun, 21 Aug 2022 at 06:34, Rebecca Cran <rebecca@bsdio.com> wrote:
> >
> > I noticed that MdeModulePkg fails to build on my Ubuntu 22.04 system
> > (and previously on the Ubuntu 20.04 installation). Is this a known bug?
> >
> > It shouldn't be relevant, but I'm using gcc version 11.2.0 (Ubuntu
> > 11.2.0-17ubuntu1). But perhaps more relevant, I'm using Python 3.10.4.
> >
> > I'm trying to build commit e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
> >
> >
> > bcran@photon:~/src/tmp/edk2$ build -p MdeModulePkg/MdeModulePkg.dsc -a
> > AARCH64 -t GCC5 -b RELEASE
> > Build environment: Linux-5.15.0-46-generic-x86_64-with-glibc2.35
> > Build start time: 22:29:18, Aug.20 2022
> >
> > 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/bin/python3
> >
> >
> > Processing meta-data
> > .Architecture(s)  = AARCH64
> > Build target     = RELEASE
> > Toolchain        = GCC5
> >
> > Active Platform          =
> > /home/bcran/src/tmp/edk2/MdeModulePkg/MdeModulePkg.dsc
> >
> >
> > build.py...
> > /home/bcran/src/tmp/edk2/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf(42):
> > error 3000: PCD
> > [gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode] in
> > [/home/bcran/src/tmp/edk2/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf]
> > is not found in dependent packages:
> >                  /home/bcran/src/tmp/edk2/MdePkg/MdePkg.dec
> >          /home/bcran/src/tmp/edk2/MdeModulePkg/MdeModulePkg.dec
> >
> >
>
> This looks like a BaseTools regression to me - afaik, these packages
> all used to build for AARCH64 in the past.
>
> The following LockBoxLib resolutions appear in MdeModulePkg.dsc (with
> line numbers)
>
> 115-[LibraryClasses.common.PEIM]
> 119:  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
>
> 178-[LibraryClasses.ARM, LibraryClasses.AARCH64]
> 181:  LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
>
> No other [LlibraryClasses] references to SmmLockBoxPeiLib.inf exist in
> that file, and the [Components] reference does not apply to AARCH64.
>
> This means the DSC parser ends up using the earlier definition, which
> I think is a bug, or at least a change in behavior. Note that doing
> this silently could potentially break many platforms in subtle ways so
> I think this should be root caused and preferably fixed before
> creating the stable tag.

Seems to be deliberate:

commit 039bdb4d3e96f9c9264abf135b8a0eef2e2b4860
Author: Chen, Christine <Yuwei.Chen@intel.com>
Date:   Thu Jun 30 17:04:05 2022 +0800

    BaseTools: Fix DSC LibraryClass precedence rule

but I don't think the impact on other platforms and drivers has been
taken into account here. Also, the document [0] seems ambiguous to me:

"""
The first globally defined library instance, defined in a DSC file,
that satisfies a module's requirement for a Library Class, unless
specifically overridden by the module in the [Components] section,
will be used.
"""

This says that the first occurrence of a library instance definition
that satisfies a INF dependency will be selected. Then, there is

"""
The Library Instances will be selected using the following rules to
satisfy a library class for each module listed in the [Components]
section (in order of highest precedence):
"""

which says that not the *first* occurrence, but the occurrence *with
the highest precedence* will be selected.

Then, the precedence list has these items:

"""
2. [LibraryClasses.$(Arch).$(MODULE_TYPE),
LibraryClasses.$(Arch).$(MODULE_TYPE)]
3. [LibraryClasses.$(Arch).$(MODULE_TYPE)]
"""

which seem to suggest that a definition that applies to multiple
arch/module_type combinations automatically takes precedence over one
that targets a single arch/module_type combination, which makes no
sense at all.

So I strongly suggest we revert the patch, fix the document so it is
clear and ambiguous, and preferably, align it with how it used to
work.




[0] https://edk2-docs.gitbook.io/edk-ii-dsc-specification/2_dsc_overview/26_-libraryclasses-_section_processing