From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by mx.groups.io with SMTP id smtpd.web11.78342.1670948664616338885 for ; Tue, 13 Dec 2022 08:24:24 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=f8eS8+BZ; spf=pass (domain: gmail.com, ip: 209.85.221.50, mailfrom: aladyshev22@gmail.com) Received: by mail-wr1-f50.google.com with SMTP id h16so7234700wrz.12 for ; Tue, 13 Dec 2022 08:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JeiMYV2Pygm5dRT9xNqQBfe2VYBzUiBtZwJL78lLH+g=; b=f8eS8+BZu73gxMMBxhDaR7WqftmhpJjwoCVNOME/TUuwaDRm9Uy58HuGCOH75nGhlJ +0HGawoU1yh3sHZQqFiIUvM0PtOz6mKawyKO+w0Yxr8VfqcG162Oo3js5yI6TWwqyUIB DukxsNdoNBjwJ1n04Pi/CGZS/48qeyeNfFsde5m/dTiRLelmQ6qxDXjoPIAJ+RjY96JY FwyaAeR+R6//24KAPmubTSDtfTJ0uumpqZi6DHhMUf57DZkvV3NqUSNOLPSnm8b95e0V MszALnGQw8T9LQ+l9vZyfjLiDa8WpEOJC92Qx+u0madq+B/Bd4W+b2rnlpe6oVeWW2Kv 8Zrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JeiMYV2Pygm5dRT9xNqQBfe2VYBzUiBtZwJL78lLH+g=; b=bMPsmW8O/FVlBhjddWI+eqPdWHtHdBtllbb3ezENzV5fZAMcmn5+k5u8ETAPqIyk8f f/jWoyxuO9JA6rp9G74ZMZ+t5Qi4LYXTAxUUj3d+ONGXG1JyTD1WL6JwBpN58cctUuGd SBs1cmRa/CaifTvpb2fTGrZn6RSdqSRite9FTrZdN3qNsC1/5MCiPdOCGEmyVDdt+w6W TqD4ZEsYM6HujxS35qj3HcBabUv6oENY42Se0AHGQkkMd9BWTg/MmROcbm6+DGr8Y/b5 +pD/S/fMrVL8Q1aH5/reQ32Vbxow/C6X8KAe6dbg1T2137ba6XlSldrVhpAUoBbmrZW3 39aQ== X-Gm-Message-State: ANoB5pm0mtv3egnsdmYe7fXYixaXC7R9VRJUNFiJ4IGl9mFKNFNPQ42Z 21SU4IPltGnwj6ou1xz+xzu+3XQoUvxou9uhWss= X-Google-Smtp-Source: AA0mqf6G+eKS10Gcg1deMiqL2ZRgTsJHBlMxPP4Vq6Bite1UvQmUUr6P+/1FgRmJT1Gt53P0yuHXjrCD9D5dOIHh1xA= X-Received: by 2002:a5d:5509:0:b0:242:5023:efcb with SMTP id b9-20020a5d5509000000b002425023efcbmr13172323wrv.143.1670948663078; Tue, 13 Dec 2022 08:24:23 -0800 (PST) MIME-Version: 1.0 References: <20221212130924.8156-1-aladyshev22@gmail.com> In-Reply-To: From: "Konstantin Aladyshev" Date: Tue, 13 Dec 2022 19:24:12 +0300 Message-ID: Subject: Re: [PATCH] Revert "BaseTools/Conf: Fix Dynamic-Library-File template" To: Jake Garver Cc: "devel@edk2.groups.io" , "bob.c.feng@intel.com" , "gaoliming@byosoft.com.cn" , "yuwei.chen@intel.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Jake! I've also verified that this change is enough to fix the cycle dependency i= ssue. I've sent an updated patch to the mailing list. Best regards, Konstantin Aladyshev On Tue, Dec 13, 2022 at 6:42 PM Jake Garver wrote: > > Hi, Konstantin, > > Thanks for working with me offline to reproduce this. > > Short answer: We can live without the "$(DEBUG_DIR)(+)$(MODULE_NAME).efi= " output and I think removing that will resolve your issue. Rather than re= vert the original change, can you submit a new patch that removes just that= line, after verifying? Thanks. > > Long answer: The problem is in how AutoGen/ModuleAutoGen.py builds up Ru= leChain in _ApplyBuildRule(). It cannot handle two outputs of the same typ= e. In this case, we have "$(OUTPUT_DIR)(+)$(MODULE_NAME).efi" and "$(DEBUG= _DIR)(+)$(MODULE_NAME).efi". In the _ApplyBuildRule(), each gets a FileTyp= e=3D"EFI-IMAGE". That looks like a cyclic dep, but really, it's just a for= k in the dep tree. I think it would be better if _ApplyBuildRule() would c= onsider the output names instead of the output types, but that would be a s= ignificant change. And one that I think is unnecessary at this stage. > > In this case, I think we can live without identifying "$(DEBUG_DIR)(+)$(M= ODULE_NAME).efi" as an output of the build rule. Then we'll dodge the _App= lyBuildRule() issue. My original issue was with an unidentified dependency= on the "map" output, but I also added the debug efi for good measure becau= se it is also an output of that rule template. However, it appears to be a= n output that nothing depends on, so it's unnecessary. > > Thanks, > Jake > > ________________________________ > From: Konstantin Aladyshev > Sent: Monday, December 12, 2022 11:07 AM > To: Jake Garver > Cc: devel@edk2.groups.io ; bob.c.feng@intel.com ; gaoliming@byosoft.com.cn ; y= uwei.chen@intel.com > Subject: Re: [PATCH] Revert "BaseTools/Conf: Fix Dynamic-Library-File tem= plate" > > External email: Use caution opening links or attachments > > > Hi, Jake! > > No, unfortunately I don't have any way to fix this, besides the patch rev= ert. > > To reproduce the issue you can add the mentioned PCI_* defines to some > simple DXE_DRIVER. > > For example: > > SimpleDriver/SimpleDriver.inf > ``` > [Defines] > INF_VERSION =3D 1.25 > BASE_NAME =3D SimpleDriver > FILE_GUID =3D 384aeb18-105d-4af1-bf17-5e349e8f4d4c > MODULE_TYPE =3D UEFI_DRIVER > VERSION_STRING =3D 1.0 > ENTRY_POINT =3D SimpleDriverEntryPoint > UNLOAD_IMAGE =3D SimpleDriverUnload > PCI_VENDOR_ID =3D 0x1234 > PCI_DEVICE_ID =3D 0x5678 > PCI_CLASS_CODE =3D 0x0001 > PCI_REVISION =3D 0x0002 > > [Sources] > SimpleDriver.c > > [Packages] > MdePkg/MdePkg.dec > > [LibraryClasses] > UefiDriverEntryPoint > UefiLib > ``` > > SimpleDriver/SimpleDriver.c > ``` > #include > #include > > > EFI_STATUS > EFIAPI > SimpleDriverUnload ( > EFI_HANDLE ImageHandle > ) > { > return EFI_SUCCESS; > } > > EFI_STATUS > EFIAPI > SimpleDriverEntryPoint ( > IN EFI_HANDLE ImageHandle, > IN EFI_SYSTEM_TABLE *SystemTable > ) > { > return EFI_SUCCESS; > } > ``` > It is enough to reproduce the issue. > Normally the build system should compile the driver code fine and then > call the EfiRom utility to produce the OptionROM image. But with the > d372ab585a2cdc5348af5f701c56c631235fe698 in place the driver build > fails. > > Best regards, > Konstantin Aladyshev > > On Mon, Dec 12, 2022 at 6:35 PM Jake Garver wrote: > > > > Hi, Konstantin, > > > > Do you have a fix for the cyclic redundancy issue when building OptionR= OMs? If not, can you help me reproduce it? > > > > I'd hate to revert d372ab as it fixed dependency issues we frequently r= an into during parallel builds. > > > > Thanks, > > Jake > > ________________________________ > > From: Konstantin Aladyshev > > Sent: Monday, December 12, 2022 8:09 AM > > To: devel@edk2.groups.io > > Cc: bob.c.feng@intel.com ; gaoliming@byosoft.com.= cn ; yuwei.chen@intel.com ;= Jake Garver ; Konstantin Aladyshev > > Subject: [PATCH] Revert "BaseTools/Conf: Fix Dynamic-Library-File templ= ate" > > > > External email: Use caution opening links or attachments > > > > > > Revert commit d372ab585a2cdc5348af5f701c56c631235fe698. > > > > EdkII build system supports OptionROM generation if particular PCI_* > > defines are present in the module INF file: > > ``` > > [Defines] > > ... > > PCI_VENDOR_ID =3D <...> > > PCI_DEVICE_ID =3D <...> > > PCI_CLASS_CODE =3D <...> > > PCI_REVISION =3D <...> > > ``` > > Although after the commit d372ab585a2cdc5348af5f701c56c631235fe698 > > it is no longer possible. > > The build system fails with the error: > > ``` > > Cyclic dependency detected while generating rule for > > "<...>/DEBUG/<...>.efi" file > > ``` > > Revert d372ab585a2cdc5348af5f701c56c631235fe698 until the issue > > is resolved. > > --- > > BaseTools/Conf/build_rule.template | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/BaseTools/Conf/build_rule.template b/BaseTools/Conf/build_= rule.template > > index af4819de92..32053f6353 100755 > > --- a/BaseTools/Conf/build_rule.template > > +++ b/BaseTools/Conf/build_rule.template > > @@ -342,8 +342,6 @@ > > > > > > > > > > $(OUTPUT_DIR)(+)$(MODULE_NAME).efi > > > > - $(DEBUG_DIR)(+)$(MODULE_NAME).efi > > > > - $(OUTPUT_DIR)(+)$(MODULE_NAME).map > > > > > > > > > > > > "$(GENFW)" -e $(MODULE_TYPE) -o ${dst} ${src} $(GENFW_FLAGS) > > > > -- > > 2.34.1 > >