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 7FFCE1A1DF4 for ; Thu, 8 Sep 2016 14:30:32 -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 EACD43F725; Thu, 8 Sep 2016 21:30:31 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-57.phx2.redhat.com [10.3.116.57]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u88LUUDM013005; Thu, 8 Sep 2016 17:30:31 -0400 To: Ard Biesheuvel References: <20160908195536.4452-1-lersek@redhat.com> Cc: "edk2-devel@lists.01.org" , Liming Gao From: Laszlo Ersek Message-ID: Date: Thu, 8 Sep 2016 23:30:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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.30]); Thu, 08 Sep 2016 21:30:31 +0000 (UTC) Subject: Re: [PATCH] BaseTools/EfiRom: supply missing machine type lookup strings 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: Thu, 08 Sep 2016 21:30:32 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 09/08/16 22:39, Ard Biesheuvel wrote: > On 8 September 2016 at 20:55, Laszlo Ersek wrote: >> "EfiRom --dump" does not recognize the 0x8664 machine type: >> >>> EFI ROM header contents >>> EFI Signature 0x0EF1 >>> Compression Type 0x0001 (compressed) >>> Machine type 0x8664 (unknown) >>> Subsystem 0x000B (EFI boot service driver) >>> EFI image offset 0x0050 (@0xF650) >> >> Add lookup strings for the remaining EFI_IMAGE_MACHINE_* numeric macros >> that can be found in >> "BaseTools/Source/C/Include/IndustryStandard/PeImage.h". >> >> Cc: Liming Gao >> Cc: Yonghong Zhu >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Laszlo Ersek >> --- >> BaseTools/Source/C/EfiRom/EfiRom.h | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/BaseTools/Source/C/EfiRom/EfiRom.h b/BaseTools/Source/C/EfiRom/EfiRom.h >> index 1214700826de..461963b4a701 100644 >> --- a/BaseTools/Source/C/EfiRom/EfiRom.h >> +++ b/BaseTools/Source/C/EfiRom/EfiRom.h >> @@ -117,6 +117,9 @@ static STRING_LOOKUP mMachineTypes[] = { >> { EFI_IMAGE_MACHINE_IA32, "IA32" }, >> { EFI_IMAGE_MACHINE_IA64, "IA64" }, >> { EFI_IMAGE_MACHINE_EBC, "EBC" }, >> + { EFI_IMAGE_MACHINE_X64, "X64" }, >> + { EFI_IMAGE_MACHINE_ARMT, "ARMT" }, > > Just 'ARM', please? PE/COFF has multiple machine types for ARM, but > EFI only uses this one for ARM (0x1c2) > > With that change, > > Reviewed-by: Ard Biesheuvel I wasn't sure if we wanted to use the edk2 architecture identifiers here, or the last _FOO substrings from the macro names verbatim. One fact that supported just picking _FOO is: "BaseTools/Source/C/Include/IndustryStandard/PeImage.h" has two mappings for Itanium (different macro name, same replacement text): #define EFI_IMAGE_MACHINE_IA64 IMAGE_FILE_MACHINE_IA64 #define EFI_IMAGE_MACHINE_IPF IMAGE_FILE_MACHINE_IA64 The identifier that you can find in the edk2 INF files is IPF, not IA64, but the above lookup strings include IA64, not IPF. This suggested that the _FOO suffixes were authoritative, not the arch identifiers that we use in the DSC / INF etc files. I'm fine either way, but I would like to hear back from the BaseTools maintainers too. Because, if we go with ARM, but keep IA64 (rather than IPF), then that's a (differently) inconsistent situation. And if we change IA64 to IPF as well, then downstream scripts that presumably parse the output might break... Fun... For now I prefer ARMT. Ugly but self-consistent (within the tool). If Liming / Yonghong agree with you, I'll be happy to repost. Thanks! Laszlo