From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0064b401.pphosted.com (mx0a-0064b401.pphosted.com [205.220.166.238]) by mx.groups.io with SMTP id smtpd.web12.37872.1641848186061345801 for ; Mon, 10 Jan 2022 12:56:26 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@windriver.com header.s=pps06212021 header.b=SNDYv5Bi; spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: windriver.com, ip: 205.220.166.238, mailfrom: prvs=8009e2c712=bill.paul@windriver.com) Received: from pps.filterd (m0250809.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 20AKSnFR020627 for ; Mon, 10 Jan 2022 12:56:25 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=windriver.com; h=from : to : subject : date : message-id : content-transfer-encoding : content-type : mime-version; s=PPS06212021; bh=wqKx87TW4p0rT2soLGyxJCIHdzoywIj9nj+xdTUOfVo=; b=SNDYv5BixUZ6rHT+D63tkuwlWKsXuln0VSSTTVqPpTnBAHbH/8QK+Df0WyMAGfyXA2uF RdIT48htG6IPW9L/R4HPmyv896GjCS9/gn6glZY8FdVCCBbBYXmgMPLxGQEVeHCQkhst X5oh0AEX/bJGS5PCek1F7x/D/diM+YVdu7X4XwN7f83Bl9unctxZcbetcSb60IH0vx/p SSy/lPkhD71RUHL56urqB6iIgUC2PkQVhGROTal3jB/XkoQN0rlc6v2pPNroytFPuxrB tXDcg6DWgOZJQ/74yZGyYBMFMe2YqiGZaF2uaROY4bOiy6XZHbsIF1oQkwEC2hhzZZvq aA== Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2103.outbound.protection.outlook.com [104.47.55.103]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 3dgmn6gawe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 10 Jan 2022 12:56:25 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GYsHez9IXNdl3kCB/SRnLnUvaSsOQBpaKa8ijgJuLrPvs0aEK32+WWUmYZjz+/6gGPCdA+i5pFRmtCcs36k5s3KKE1sN1/lJiOWB26UGjA6DrV16Yrp4dT/ScR0FpcOC+el3YDHJ8+h80YOIqyYXdfCI+922T2OM/qI5FQSTVx+4mloz6Gw6EaEdKGuPI/PoVDNj7VnUnG/85ItZx+C+nwqzjUxuzaRBj35l6rBeD2VVEq5yxsEu1kjn1x7bBaFT3Z/fSi3HeWujmr9BCweNkwfzRxnybN6f2pDK5JP88Xgr8yLHx/MaoXV66AvtdIRYIKiXFqxfWquewRNEZVOzkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wqKx87TW4p0rT2soLGyxJCIHdzoywIj9nj+xdTUOfVo=; b=IT/ZOtm4xPwmEtkkjfyh9yPKg7SmmPLIQbu5lGN9P3sbonfaY0/yPIS4JvnJaZdIDN92bAKN3LjQ5GdUmZBCYS2bxGEbuWEh6+tdCVGk8bXtX3E0hBKvjx+HLMl7vWaFV42luFcCxwYIYsZ5pwl8hf6qxF31ZsFsL78/exlKwOCJiAwLeXnkOW552ZQIGwgvcJ5aqjrUOsLeBLE+5gjPX6iPRQDl4blt2p1EFE1Sig44cycxbLTj/7ICxBNLFFJrT2S7WX6J3kMXlgiy8EBeS+pXs87/CbPyNiFO/qDusqiclpKNKf/QsV00J8LBINsxTMW9Ruq+sm3dr3eTfB4LZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=windriver.com; dmarc=pass action=none header.from=windriver.com; dkim=pass header.d=windriver.com; arc=none Received: from CO1PR11MB4962.namprd11.prod.outlook.com (2603:10b6:303:99::23) by CO1PR11MB4833.namprd11.prod.outlook.com (2603:10b6:303:99::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.7; Mon, 10 Jan 2022 20:56:24 +0000 Received: from CO1PR11MB4962.namprd11.prod.outlook.com ([fe80::3cc3:4451:ed15:ae8b]) by CO1PR11MB4962.namprd11.prod.outlook.com ([fe80::3cc3:4451:ed15:ae8b%6]) with mapi id 15.20.4867.012; Mon, 10 Jan 2022 20:56:23 +0000 From: Bill Paul To: devel@edk2.groups.io Subject: Issues with CLANGDWARF tool specification and X64 -- am I nuts or what? Date: Mon, 10 Jan 2022 12:56:20 -0800 Message-ID: <1670021.xRuIxZukmv@core> Organization: Wind River Systems X-ClientProxiedBy: SJ0PR13CA0020.namprd13.prod.outlook.com (2603:10b6:a03:2c0::25) To CO1PR11MB4962.namprd11.prod.outlook.com (2603:10b6:303:99::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0baf9ebf-ac12-444a-2a36-08d9d47ba954 X-MS-TrafficTypeDiagnostic: CO1PR11MB4833:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qefOo3AHMk+k42Ta1dM1nxDh7WR6afAwbxaAyNpgxlC/nRWbAxpEW5qXHRNqukg7gR616c+la0sim/0cuKoxeTNiQpBnqH2t2lZHCPkdtuVX0hIgVXjndWPySKbVu9rx17wS9dsW+95i/nkJm0x2C2uPQt9wMAAu0/ygd4t2v0flTye/T5zCtfw6Blow/4R+cMZgopAHJkU6/qhKVoGHnXpjDgMmjJLD+1QRRP6OwDG1MxL/BJRrZ7jnTtBWVG3tGbaT2/yfZTwV+gxeV7+vY2kKMPhxcvdsIwlSvkA+omKSxtiItEMtgrvJ3d/4lbcezsDKiZp34Qtil3icJBfD1WKR1XOsR79vj+SW/UFEhA22ETY9QvP7EjBv/l5A2elsqTYWNUus1qNwGIyhXZcEouNLU/PZpIQd0Dub2uqD9ezn6jKerfMPSe38XH+/DWTGPCJ6k/wJQdTTGq3SGn+8Oclb77VcRgnZPZJsldSuaHR0BX8bPVlM2LmMhovaqoTKTywOo+Mi0cycb8smIhzcPNK1bkGOHWxmo0ePo5Stin64orOP75a1askYOkTowk9iaziKK21l1SsuzPXNIuqHcPRzbQ7E0s0qeyNZsWig5CF05t4MQVCajton6Ib0rd0ZFK8qQKLBX81rpCwjRgUWwaZVIDNo5Dp+hLdNdgzH40LSQz7RJj4lUr8OeQTZ34MgSDm0u0GUQyV9tpRrfp4ZHg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR11MB4962.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(7916004)(366004)(33716001)(316002)(83380400001)(2906002)(26005)(38100700002)(5660300002)(9686003)(40140700001)(52116002)(6916009)(36916002)(6486002)(8676002)(8936002)(38350700002)(186003)(6512007)(508600001)(66556008)(66476007)(66946007)(6506007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?0oE1GJzawEeNDCh7LEZAjfN90ovVDQV+gPkBiGa1sqvbT4QAn8nt8vEhdEMB?= =?us-ascii?Q?41zui5BEHsATVBvZPAFGIR47QV/ZBpGP0rGU16Hy0vA3QHvEterYb2YzJp6o?= =?us-ascii?Q?9tXOmz7x443n7koBKHephWedqBGIQ2TvCvuXmNXSOB3nGa0GH2bxupvVHjzk?= =?us-ascii?Q?VJ4qfNay8C3lbK/IV+ULxzEr2ftQ3gQnfLsSptFthLCoDfVhiTiHn1fVxaqz?= =?us-ascii?Q?7pq+0/hweXC4GaO8ftu84jUIW65FYu3jnlrd6JjRclrQnkI50kAOkYKwNybQ?= =?us-ascii?Q?M7D98PnEb4OePM1C1fcLge8hbst6jABURE6zU4MOipgYYtOWKgGyLfNrr7Wf?= =?us-ascii?Q?2fNpTyUR/E0DEpk0t9sOAHyIIe4fDqYpLvgd8BGKpi2XBw5HvcBxD0d69JPp?= =?us-ascii?Q?KTmuatGcXlW06kMPIxqFuDIBTty6YVRMU2lf/4qZIw/ixynb5cmuuj/jnjSV?= =?us-ascii?Q?avo5VoBC3X5vWULHifr/Hr8mhVVZY9fr22jGR8qejeVbqEZOhk+WiW+vn5dk?= =?us-ascii?Q?Gwk19B/nPTRczflh8j/8n0UEwL9hSEWB9ZB3+f7BZBr0gR5wKolCuXoL+9uZ?= =?us-ascii?Q?v/Zlbg6gQzM/llYRBpDlvCTbF87yzHgMT8CMr8i6r1H3za9nnBlvm7dfYxAO?= =?us-ascii?Q?uTANL3TXjZ3f0GrOt1xbEklLR7YbnLTz9ntPNXcxz+fQxNt7aUFSyXP1jhGm?= =?us-ascii?Q?ABIsBOTtRDE71i9QlPzwo4r+JbI7xGEoLJCETaYmU38kiGCpIh1iyj9VUNvz?= =?us-ascii?Q?raiuO2NPsap9ivu1IJ2M4km0DeZXTl4rGoqUD7EzcT7Y1srxFWniQX9cVGx0?= =?us-ascii?Q?2Gsil8bmv8JUyF8jHzUYYlySYKqpwJ4V2rmShrFS8ELQF/f4kriNg+yDdZ+m?= =?us-ascii?Q?9JrEpbyA4o4RzO4FJo54dIiI5AWaK4nefYWyKtQLPaG49EIO5XiQdtElsWH7?= =?us-ascii?Q?xxKpQ89Wgp71y01aZWclFewXcQxlMNCdyiBPfrYJhnJ4r+t9Pft6abKw5uk5?= =?us-ascii?Q?RyN/y6GAf/gk48t6NlxDIMkjWSMRzSNYxr+OVZ3GD27aDkjXQSu9J+h1BDnU?= =?us-ascii?Q?im1kPvFbLM8f9WYGoeUTeOj/WNYJVskHvPgIxOzJA4diL2HG23TXVAwNhcmm?= =?us-ascii?Q?MwSndK2kjHCfQOycKqoD1OcnsCS3THHOtsURCTxtYlqLtMFDrNSd1ETxrOeR?= =?us-ascii?Q?OFg9ydpu1GqLxSuNaVQnWFKtCwqadXrMXkAAFacyNIgYcZTKU+HCRHY5NARd?= =?us-ascii?Q?eDYSq2VD0KZPdYj6EFSvf0s0upLHi2XELRysJCZwgG/3XsvyD03kqyQXmBkg?= =?us-ascii?Q?aT93KOX+ygQZJnYA/M/V6u17LxfOS6lWXAiO5qfIlGqOnQHusA+hWz0U/5fg?= =?us-ascii?Q?FsqRXjYDAYACSUQEQPDjtIl6EaUZbt8VuIZnxLRhsFdXoGYCd++lCr6cDq8a?= =?us-ascii?Q?AZT5hGttc+NE9ckIuITOkezOey4wnNSdy0bDxb9q7QGnXBQbDEzi02TplYp9?= =?us-ascii?Q?NTMweCvQ0TTP42EvB9Jxp9WOwTA0nD4ZfOai4/GbrJa9+OB1Hj92cGzlJB01?= =?us-ascii?Q?Pkne+Qsf3ZXfSXz7nxzPYP7jmUhDeyVxDpsCdE18ZalFC/qG134XUFA6f/o4?= =?us-ascii?Q?aQLWIO74FmIm/5NoQxf7wzo=3D?= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0baf9ebf-ac12-444a-2a36-08d9d47ba954 X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4962.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2022 20:56:23.7973 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9lcPClfPXCO6gu+Kqk+TbOw6Lh04cvwNhaR1XJmrVkzDC/XUCKprxTCk8dEDCnm91mkBl0ndCDzvJzSeo2pkXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4833 X-Proofpoint-ORIG-GUID: 4l_uqUfD-x8hLwA7CveKDZiWtTUAIoUh X-Proofpoint-GUID: 4l_uqUfD-x8hLwA7CveKDZiWtTUAIoUh X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-10_09,2022-01-10_02,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 bulkscore=0 adultscore=0 mlxscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 suspectscore=0 priorityscore=1501 clxscore=1011 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2201100140 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hello all: Recently I discovered that you can enable CSM compatibility mode in OVMF and decided to build some images with this feature Because Of Reasons (tm). My platform is: FreeBSD/amd64 12.2-RELEASE Clang/LLVM 10.0.1 QEMU 6.2.0 These days FreeBSD uses Clang as its native compiler. 12.2-RELEASE comes with version 10.0.1, but you also have the option of installing more recent Clang/ LLVM versions up to 12.0.1 as supplemental packages. I noticed that CLANGDWARF is a supported tool spec for the X64 and IA32 build targets so I decided to try that. Unfortunately I ran into a couple of problems: 1) Compilation of OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c fails due to uninitialized local variable. /mnt/home/wpaul/edk2/edk2/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c: 1875:9: error: variable 'Compacted' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (EcxIn == 1) { ^~~~~~~~~~ /mnt/home/wpaul/edk2/edk2/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c: 1895:12: note: uninitialized use occurs here Compacted ^~~~~~~~~ /mnt/home/wpaul/edk2/edk2/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c: 1875:5: note: remove the 'if' if its condition is always true if (EcxIn == 1) { ^~~~~~~~~~~~~~~~ /mnt/home/wpaul/edk2/edk2/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c: 1871:37: note: initialize the variable 'Compacted' to silence this warning BOOLEAN Compacted; ^ = '\0' I changed line 1871 to: BOOLEAN Compacted = FALSE; and that fixed it. I suspect this may be a case where Clang is being a bit more strict than GCC about uninitialized variables. 2) Linking fails with numerous errors of the following kind: ld.lld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,- z,notext' to allow text relocations in the output >>> defined in /mnt/home/wpaul/edk2/edk2/Build/OvmfX64/RELEASE_CLANGDWARF/X64/ UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib/OUTPUT/ SecPeiCpuExceptionHandlerLib.lib(ExceptionHandlerAsm.obj) If I edit tools_def.txt and change RELEASE_CLANGDWARF_X64_DLINK_FLAGS so that it includes -Wl,-z,notext as the error suggests, then everything links as expected. (The same thing is needed for DEBUG_CLANGDWARF_X64_DLINK_FLAGS and probably NOOPT_CLANGDWARF_X64_DLINK_FLAGS.) This problem only occurs when building for X64. IA32 seems ok. Is there any particular reason why these flags aren't there already? 3) Although fixing the above two problems allows me to produce a complete OVMF.fd image, it crashes at start-up with the runtime error: !!!! X64 Exception Type - 06(#UD - Invalid Opcode) CPU Apic ID - 00000000 !!!! RIP - 000000007EC8A7DB, CS - 0000000000000038, RFLAGS - 0000000000010206 RAX - 0000000000000000, RCX - 000000007F5A0880, RDX - 000000007FF2BAE0 RBX - 000000007FF2BBF0, RSP - 000000007FF2BB20, RBP - 000000005A1C5000 RSI - 000000007FF2BB48, RDI - 0000000000000000 R8 - 0000000000000008, R9 - 0000000000000000, R10 - 0000000000000000 R11 - 000000007FF41C90, R12 - 0000000000058080, R13 - 000000007FF2BC20 R14 - 00000000000F6DB0, R15 - 0000000000000000 DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 GS - 0000000000000030, SS - 0000000000000030 CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 000000007FC01000 CR4 - 0000000000000668, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 000000007F9EC000 0000000000000047, LDTR - 0000000000000000 IDTR - 000000007F5A4018 0000000000000FFF, TR - 0000000000000000 FXSAVE_STATE - 000000007FF2B780 !!!! Find image based on IP(0x7EC8A7DB) (No PDB) (ImageBase=000000007EC87000, EntryPoint=000000007EC8D7A6) !!!! The same thing occurs for IA32: !!!! IA32 Exception Type - 06(#UD - Invalid Opcode) CPU Apic ID - 00000000 !!!! EIP - 7ECF72D4, CS - 00000010, EFLAGS - 00010206 EAX - 00000008, ECX - 00000000, EDX - 7F8EEE10, EBX - 5000A19D ESP - 7FF33D44, EBP - 7FF33E4C, ESI - 7FF33D4C, EDI - 7ECFB04C DS - 00000008, ES - 00000008, FS - 00000008, GS - 00000008, SS - 00000008 CR0 - 80010033, CR2 - 00000000, CR3 - 7FC01000, CR4 - 00000660 DR0 - 00000000, DR1 - 00000000, DR2 - 00000000, DR3 - 00000000 DR6 - FFFF0FF0, DR7 - 00000400 GDTR - 7F9EC000 00000047, IDTR - 7F5E5010 000007FF LDTR - 00000000, TR - 00000000 FXSAVE_STATE - 7FF33A80 !!!! Find image based on IP(0x7ECF72D4) (No PDB) (ImageBase=000000007ECF4000, EntryPoint=000000007ECF9FBD) !!!! This one had me going for a while, but I eventually traced it down to LegacyBiosInt86() in OvmfPkg/Csm/LegacyBiosDxe/Thunk.c. In that function, there is this code: UINT16 Segment; UINT16 Offset; [...] // // The base address of legacy interrupt vector table is 0. // We use this base address to get the legacy interrupt handler. // ACCESS_PAGE0_CODE ( Segment = (UINT16)(((UINT32 *)0)[BiosInt] >> 16); Offset = (UINT16)((UINT32 *)0)[BiosInt]; ); As the comment notes, here, we're trying to directly read from address 0 using BiosInt as an offset. This seems to trigger a problem with the Clang optimizer. The disassembled output looks like this: 0000000000003786 : 3786: 56 push %rsi 3787: 48 83 ec 60 sub $0x60,%rsp 378b: 41 0f b7 40 18 movzwl 0x18(%r8),%eax 3790: 25 d4 0c 00 00 and $0xcd4,%eax 3795: 0d 02 30 00 00 or $0x3002,%eax 379a: 66 41 89 40 18 mov %ax,0x18(%r8) 379f: 48 8d 74 24 28 lea 0x28(%rsp),%rsi 37a4: 48 83 66 18 00 andq $0x0,0x18(%rsi) 37a9: 48 8b 05 a8 59 00 00 mov 0x59a8(%rip),%rax # 9158 37b0: 31 c9 xor %ecx,%ecx 37b2: 48 89 f2 mov %rsi,%rdx 37b5: ff 50 38 call *0x38(%rax) 37b8: 4c 8b 46 18 mov 0x18(%rsi),%r8 37bc: 41 0f ba e0 0d bt $0xd,%r8d 37c1: 73 18 jae 37db 37c3: 48 8b 05 8e 59 00 00 mov 0x598e(%rip),%rax # 9158 37ca: 49 81 e0 ff df ff ff and $0xffffffffffffdfff,%r8 37d1: ba 00 10 00 00 mov $0x1000,%edx 37d6: 31 c9 xor %ecx,%ecx 37d8: ff 50 40 call *0x40(%rax) 37db: 0f 0b ud2 <--- er... what? Note the "ud2" instruction. I have no idea what that's supposed to be, but it looks like Clang just gives up generating any further instructions once it hits this code. I reduced this to a very simple sample C program that also reproduces the problem: #include extern int somefunc (uint16_t s, uint16_t o); int foo (uint8_t BiosInt) { uint16_t Segment; uint16_t Offset; Segment = (uint16_t)(((uint32_t *)0)[BiosInt] >> 16); Offset = (uint16_t)((uint32_t *)0)[BiosInt]; return somefunc (Segment, Offset); } If I compile this with: % clang -O2 -c edk.c then I get this: 0000000000000000 : 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 0f 0b ud2 If I compile with GCC instead: % gcc10 -O2 -c edk.c then I get this: 0000000000000000 : 0: 40 0f b6 ff movzbl %dil,%edi 4: 8b 3c bd 00 00 00 00 mov 0x0(,%rdi,4),%edi b: 0f b7 f7 movzwl %di,%esi e: c1 ef 10 shr $0x10,%edi 11: e9 00 00 00 00 jmp 16 If I compile with Clang using -O0 to disable optimization, then it produces code: 0000000000000000 : 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: 48 83 ec 10 sub $0x10,%rsp 8: 31 c0 xor %eax,%eax a: 89 c1 mov %eax,%ecx c: 40 88 7d ff mov %dil,-0x1(%rbp) 10: 0f b6 45 ff movzbl -0x1(%rbp),%eax 14: 89 c2 mov %eax,%edx 16: 8b 04 91 mov (%rcx,%rdx,4),%eax 19: c1 e8 10 shr $0x10,%eax 1c: 66 89 45 fc mov %ax,-0x4(%rbp) 20: 0f b6 75 ff movzbl -0x1(%rbp),%esi 24: 89 f2 mov %esi,%edx 26: 8b 34 91 mov (%rcx,%rdx,4),%esi 29: 66 89 75 fa mov %si,-0x6(%rbp) 2d: 66 8b 45 fc mov -0x4(%rbp),%ax 31: 0f b7 f8 movzwl %ax,%edi 34: 0f b7 75 fa movzwl -0x6(%rbp),%esi 38: e8 00 00 00 00 call 3d 3d: 48 83 c4 10 add $0x10,%rsp 41: 5d pop %rbp 42: c3 ret Note that this is with Clang 10.0.1, however I observe exactly the same results with Clang 12.0.1. I was able to fix this locally (for both X64 and IA32 targets) this by doing this: UINT16 Segment; UINT16 Offset; volatile UINT32 * Page0 = NULL; [...] ACCESS_PAGE0_CODE ( Segment = (UINT16)(Page0[BiosInt] >> 16); Offset = (UINT16)Page0[BiosInt]; ); Note that the addition of the volatile keyword seems to be the key. If you wanted to make the change simpler, you could also just do this: ACCESS_PAGE0_CODE ( Segment = (UINT16)(((volatile UINT32 *)0)[BiosInt] >> 16); Offset = (UINT16)((volatile UINT32 *)0)[BiosInt]; ); (To my eyes, the other way is more readable, but others may disagree.) With these three issues fixed, I'm able to boot and run my OVMF.fd images for both X64 and IA32, and they're able to also boot and run the loaders and OS images that I'm testing. I'm not sure how much testing the CLANGDWARF toolspec is getting these days, but maybe it should get a little more. Is there any chance these issues could be addressed? -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | VxWorks Software Architect, wpaul@windriver.com | Master of Unix-Fu - Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin =============================================================================