From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5E5741A1E3A for ; Mon, 24 Oct 2016 04:50:56 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BE00D4E4D7; Mon, 24 Oct 2016 11:50:55 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-107.phx2.redhat.com [10.3.116.107]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9OBoqkx020568; Mon, 24 Oct 2016 07:50:53 -0400 To: Ard Biesheuvel References: <20161021212737.15974-1-lersek@redhat.com> Cc: edk2-devel-01 , Anthony PERARD , Gary Lin , Jordan Justen , Leif Lindholm , Liming Gao , Michael D Kinney , Michael Zimmermann From: Laszlo Ersek Message-ID: Date: Mon, 24 Oct 2016 13:50:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 24 Oct 2016 11:50:55 +0000 (UTC) Subject: Re: [PATCH 00/19] OvmfPkg, ArmVirtPkg: leave deprecated interfaces behind X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 11:50:56 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 10/24/16 10:04, Ard Biesheuvel wrote: > On 21 October 2016 at 22:27, Laszlo Ersek wrote: >> This series intends to solve the following BZs: >> >> -- OvmfPkg: Add >> the build option "/D DISABLE_NEW_DEPRECATED_INTERFACES" in package DSC >> files >> >> -- ArmVirtPkg: >> Add the build option "/D DISABLE_NEW_DEPRECATED_INTERFACES" in package >> DSC files >> >> Public branch: >> . >> >> The DISABLE_NEW_DEPRECATED_INTERFACES feature test macro disables the >> following MdePkg library class APIs: >> >> BaseLib: >> - StrCpy, StrnCpy, StrCat, StrnCat, UnicodeStrToAsciiStr, >> - AsciiStrCpy, AsciiStrnCpy, AsciiStrCat, AsciiStrnCat, >> AsciiStrToUnicodeStr. >> >> PcdLib: >> - PcdSet8, PcdSet16, PcdSet32, PcdSet64, PcdSetPtr, PcdSetBool, >> - PcdSetEx8, PcdSetEx16, PcdSetEx32, PcdSetEx64, PcdSetExPtr, >> PcdSetExBool. >> >> UefiLib: >> - GetVariable, GetEfiGlobalVariable. >> >> The series gradually weans the OvmfPkg and ArmVirtPkg modules off these. >> For the 32-bit ARM builds of ArmVirtPkg platforms, I had to dip my toes >> into ArmPkg a little bit, due to dependencies. >> >> I couldn't build-test some changes (for example, the only compiler >> toolchains I have access to at the moment are GCC48 for Ia32/X64, and >> GCC5 for ARM/AARCH64). Some changes I could build, but not functionally >> test (Xen en bloc, 32-bit ARM, RAM-emulated variables in OVMF, -bios >> flag). For all of these, I liberally sprinkled the patches with Cc's and >> Notes sections, asking for help. I did make an honest effort to build >> the ArmVirt and OVMF platforms in as many configurations (-D ...) as I >> could think of, perusing the various !if directives in the DSC files. >> > > I tried ArmVirtQemu.dsc in DEBUG mode with RVCTLINUX, and it built fine* > > Tested-by: Ard Biesheuvel # RVCT Thank you! Then, > * In general, RVCT tends to fall over quite regularly due to its > finicky diagnostics, so I did have to apply this patch > > """ > diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c > b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c > index ca61ac5e1983..1098d9501cc7 100644 > --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c > +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c > @@ -891,7 +891,7 @@ NorFlashRead ( > SEND_NOR_COMMAND (Instance->DeviceBaseAddress, 0, P30_CMD_READ_ARRAY); > > // Readout the data > - AlignedCopyMem (Buffer, (VOID *)StartAddress + Offset, BufferSizeInBytes); > + AlignedCopyMem (Buffer, (VOID *)(StartAddress + Offset), BufferSizeInBytes); > > return EFI_SUCCESS; > } RVCT is correct here; standard C does not permit arithmetic on pointers-to-void. From C99 for example, 6.5.6 Additive operators ... Constraints 2 For addition, either both operands shall have arithmetic type, or one operand shall be a pointer to an object type and the other shall have integer type. [...] "Pointer to void" is not "pointer to object type". Although in 6.2.5 Types we have 27 A pointer to void shall have the same representation and alignment requirements as a pointer to a character type. [...] but also: 19 The void type comprises an empty set of values; it is an incomplete type that cannot be completed. So, not an object type. Can you submit this patch per se? It's a valid and justified change. > diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf > b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf > index 812dafd065b2..0ef7b8d81bbc 100644 > --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf > +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf > @@ -71,3 +71,7 @@ [Depex] > # NorFlashDxe must be loaded before VariableRuntimeDxe in case > empty flash needs populating with default values > # > BEFORE gVariableRuntimeDxeFileGuid > + > +[BuildOptions] > + RVCT:*_*_*_CC_FLAGS = --diag_suppress=6314 > + > """ No input on this though :) > but these changes are entirely unrelated to the series, and I will > follow up with some patches to fix this. > Yes, please. Thanks! Laszlo