From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0064b401.pphosted.com (mx0b-0064b401.pphosted.com [205.220.178.238]) by mx.groups.io with SMTP id smtpd.web10.12463.1641927816975727495 for ; Tue, 11 Jan 2022 11:03:37 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@windriver.com header.s=pps06212021 header.b=lpydLKng; 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.178.238, mailfrom: prvs=80105383a1=bill.paul@windriver.com) Received: from pps.filterd (m0250812.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 20BIYBX4013485 for ; Tue, 11 Jan 2022 19:03:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=windriver.com; h=from : to : subject : date : message-id : in-reply-to : references : content-transfer-encoding : content-type : mime-version; s=PPS06212021; bh=oTRI3Yshs/oa09sDBkznRNJjT2cmJ6sC8m9gOqVGAeQ=; b=lpydLKngh7v9L2iQ3wcUtLxzn4MTLtOhaKC6354zJlCKYp7KTYiwhhdzMieHjrrBOkNB 9k0crYFDmvDfeaXZueWhVqn91YvKoSmovv2bidF3E9rknFWA48Z/EcOLbVU1v3/G0JdT rMTwzLMZLZMm8EY2NyaNLLjTSgMJb2z9vBxGDngTU3QjAhy8P9TsOMQQCfaRkKbg9FhZ RKpHWa6WkiTQlu7vBGVr3D5ykrT54m/RKV+kJYwWcom3oOrN49PX/mGEQf6K8t/j1ldz 9WDLuwQCbC23d7bVg5uS45u56zbMR2nodX6ZXk4n4oTqCdiz/kA58eQBW9uyzUT7CMUz 6A== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2170.outbound.protection.outlook.com [104.47.55.170]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 3dgdxj1amq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 11 Jan 2022 19:03:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UtnITd4lG8xsg5xeGql8PGvlf+ERZ4ckdO2Vm9XZFD1dmV/Ejcph1Z2QaqQu431IUuwV5Hk6ggjasYSeAAZsayM9egEUIcqRbFeczp3d/ajgEIdbJEOmc5GU1nu51eDYdq8XfmGg+gi3RbCLQDz5+S/OgFf01rTANBZm090ZaefQdqVRX4wDMxGtVhDlXK4OmjuQYz2BUUm1kSytN8kYeiVxwXQy8tMP5Ttv43bJHr/VFSo5Go6e34IBAdLpUVyMKPsX+dfUtmSk8WiWqyFzKf+++a63cKAXSvsJR7rw29oktpX/sOKwyXAlPqZuxFLp3iMeherlrUk1X3tbKtlUfQ== 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=oTRI3Yshs/oa09sDBkznRNJjT2cmJ6sC8m9gOqVGAeQ=; b=Js8C1LwmJ3F7Myf19A8vFDnKyE0TcT5IdySFe0m1+0j395Fkb+dajE34Pmtz2hMvcr7Y4e4dJpAXN5mh+INWDUCDLxscpWKA8CEn+OOWQYu450m0EJs1XnZqqJBKoh22bNPCfS2/pWDt8ssw7aMF7ti1pP8tO+W1SY2uXQCAlhbimDyg/bxHg22nNDP+AE0SJ+t/zPV4aM5vYooYZ4OCdR13XWUux/yMAzPOyqDUL41L7Jx0G0/hU4/DsqW6MmxzNPAxjTZOYW8VUvEtzzezcjxT+IMMx7WsWyom12PlRV/lULbeuPlrOZuu4+wX9EYzMCEL1FqowBn4AxnPrvApsQ== 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 MWHPR1101MB2078.namprd11.prod.outlook.com (2603:10b6:301:4e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.9; Tue, 11 Jan 2022 19:03:33 +0000 Received: from CO1PR11MB4962.namprd11.prod.outlook.com ([fe80::e8be:f48f:ba31:ffc4]) by CO1PR11MB4962.namprd11.prod.outlook.com ([fe80::e8be:f48f:ba31:ffc4%3]) with mapi id 15.20.4888.009; Tue, 11 Jan 2022 19:03:32 +0000 From: Bill Paul To: devel@edk2.groups.io Subject: Re: [edk2-devel] Issues with CLANGDWARF tool specification and X64 -- am I nuts or what? Date: Tue, 11 Jan 2022 10:02:41 -0800 Message-ID: <1919126.R0FQcr2YjX@core> Organization: Wind River Systems In-Reply-To: <1670021.xRuIxZukmv@core> References: <1670021.xRuIxZukmv@core> X-ClientProxiedBy: BY5PR17CA0048.namprd17.prod.outlook.com (2603:10b6:a03:167::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: 35907da6-6d13-4001-7003-08d9d5350fce X-MS-TrafficTypeDiagnostic: MWHPR1101MB2078: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: f5Dr5qijIIrGw62c/bKdqq4lI82q4oOs1rIDfGlJC6iC3mqXw0CQMRyJ1Abl6sHebEXRnKtyzQgweH0qss+PLNVnfZiqh64afq92EFhxxieFGi8AqlLn7vK/6qlUL+tAJuXanKw9RP2Y+E3hthMfnub+5NwqSUUo9q2I1pgvsxj46152Jl5546xYDeDLC1rkHbDlucsRa+JBjwpfdK8e2eIVS3GSnC1pSgHWk4di3zIeIVi+cju1/bPhytVI1NEXE3pkQfEb7RLYMkvdgz/Pt1gJUUbxtIILTkLLWTkTxnzxv3nFTeeWz0BqDyOjAnLf8BoN5O6iGZ2YV8HtTI0nemp2bdemQFHj9sr3rbxlmVw62GIq/l92nFl5MlUM/AdG/dQbya4Kir7ZNzM1We/pTBX6TBhX6JsH7NBE78ER85pLe8RZ8uvkkVQTDJ45N0JGaswgmezLPJpX5M6YqlginKRL1aq4cInFquE8pEttWoLDm1gL1k2VmkyT4h2+qCzyoNRXMxQkKtoU6eMo8Amc8XV4/Y1d2gTCeC/OnCxWFsKd/nhOWkIENbCGqPoEMrVEkQmZlh0Niqjvj+ASeGGMaok3TmepCzqJS9MVma7qrds+o83gIPrXXFwZszoWAvPMjjLmsVmEMAotkiL6qGpfqaumAibHHSdfn+E6+D/45mpXPM0V3ZVJuCysHqolYHIV6vaCeWtiZrCAqAGnJdt0Jp1aH1UwrLpSztaaH9dATX4= 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)(8676002)(83380400001)(6666004)(36916002)(66476007)(66556008)(52116002)(66946007)(316002)(38100700002)(38350700002)(2906002)(8936002)(40140700001)(26005)(6486002)(30864003)(186003)(9686003)(6512007)(6916009)(508600001)(5660300002)(33716001)(6506007)(39026012);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ZFNSNM4yMf86/PkPsHum0gSA/EDyWncKk7ljy5ZRH/Ism6pW4OPmfPVumsZ2?= =?us-ascii?Q?FnM7nSEUcync7+bR6qizVKTCizXPt15G302a7tl/XeTxdtWbKFq2XzdQGCM6?= =?us-ascii?Q?//3khBu9lkZt6oncU5FXEBrCCKHfemmJSdP3yAz49MAV/Sxaj15Orqae9A+y?= =?us-ascii?Q?rFylAaXiBpQhnP2yowqOvHzCZZN9027ThcvibJcmgtpkWqwbOOzaPPFhwXbl?= =?us-ascii?Q?Hr3c2ZYqK9d9thUC9fWNmd/qK2Q/C0DpaE1hOxnCVXMTGmhYGfWc42/DM0p+?= =?us-ascii?Q?Z/Ie7fsuylAOon7Hb92DKTGtfwHrFkwkspeRvKx9yka2Sq/UBBwK6DonSTgr?= =?us-ascii?Q?XN4Wq60SSLEtHNZP60aq4BFgc1ejMbmc6IXWBq6+9nYJb1IfOykEPVeaU850?= =?us-ascii?Q?1SBiQww+rIaialm2q4kyrjhV5z8rv7dV+OV9X1frRly1rm2FzvLP7bDhlpwi?= =?us-ascii?Q?BMXqUAcWyqrVNdabO432QkNwZ+kB6RSZX0z2+xLV94zcTdi65NX7geqSocNi?= =?us-ascii?Q?5AdiiWO37FEmzXEBntyMZCsdkxQnykxmP5cOx4ZzpQj1nxBLH15vItFRVruQ?= =?us-ascii?Q?64W9vovCyYer6awOJT6Mjq7ObjZbxx/W4FryxFk6g4arS6LM3oCd0AWOVke5?= =?us-ascii?Q?RgqD0xzaU1pewnWHd1gh8y2bLjmqNoSd3v5BnpDPbSAEoQ0Aj7GNULkVISD8?= =?us-ascii?Q?lOZjFflA1EuEW9BfV/Ca8GcSOFG5N0sEkLG/iLFIjokjYdLlG1xLp+Snsuyr?= =?us-ascii?Q?onLL1RKmU4ZSgI9ssI88VLtMu+CjKXl+GM/G48yWCU/z13r3+hYa1Om1jj5s?= =?us-ascii?Q?CB7dwHQv8+rbEsh3rFoqPsDoI0UHlh7pFmzr90pM+4UItCeusu/Rin13mrXc?= =?us-ascii?Q?lD4WfYNMDgmc1GY3pW5uLVyB8DDdwnuX+F/MSXHWaMyoWLfDlKSO3d1nbhQc?= =?us-ascii?Q?VVJalNIO459YMIjR2xnvSZ1tp1wvfqcj0I3exzNUxRW6ZXlYA0cASWzHUmtR?= =?us-ascii?Q?72QB/kFYeiBo5wg044qCgbQseUKg9EwWpnrkdbunHozfxhKSE4mrK5bOkHPk?= =?us-ascii?Q?Hxu75VtHiZcWewdW+u8Tmia6kiSS4ThTMECcTuNxULX2gj+lNgvIUyaxPFlK?= =?us-ascii?Q?awh1qiNZrKmBAe1sfMDF6qiRiMkLNe7v+XxZEfm16ubMnHKTYjA+lrPICyUB?= =?us-ascii?Q?yd6FpXlO4JoXtJHt/TxaW1x21OoEG4QBMNOCB1tLaGNtxs9qaDpE+QB9OsYu?= =?us-ascii?Q?X8thRKzW76ue4bIrmTuaaC9CMUmfEDoUvLfxldoyKbyTMqEC+dhU8nQfmrMU?= =?us-ascii?Q?76e7Hb1Wy2pmnKYeu9uJVtcwF6SsLbJP8Sz2Nk7kXSs+3ez86uvEtxCZ0jAl?= =?us-ascii?Q?7RC3YDRqADmC+4zNJzYlpP/1fqJUvh3dSZo5iA1TvPeeXmvY33SOVaoeERt7?= =?us-ascii?Q?0cjHGIHmuZx6OJfue+/hYChWM8OOSGTelCDtwSnpNeqUHJlCbVWw7UOxPNir?= =?us-ascii?Q?LWscF2HmoZXoBwL5x+tjXFuHg3i5A6aSMI0W0PHd1l5QpGbRhiOcF2vr6JrZ?= =?us-ascii?Q?WvTKGB2BrmDfx3Z+xHrJBxph7JJ5EFqnL1T993R+h3KnpHHYIV4Q1BicmgUl?= =?us-ascii?Q?RN3JDpkCoJgAP971e9rMM+s=3D?= X-OriginatorOrg: windriver.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35907da6-6d13-4001-7003-08d9d5350fce X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4962.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2022 19:03:32.7072 (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: bZiClI5B6nqi5SCs8yav1M8kmFNHFebg7Ec1tQ0mJlo+o0WL9rNy0ucbSAKcA6SosRUncMRZ1b9EzTrmNeKL2g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2078 X-Proofpoint-ORIG-GUID: Slb5QqZSlG2_TWj08qiN4tm7DJDh867C X-Proofpoint-GUID: Slb5QqZSlG2_TWj08qiN4tm7DJDh867C 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-11_04,2022-01-11_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 spamscore=0 impostorscore=0 suspectscore=0 clxscore=1015 mlxscore=0 adultscore=0 bulkscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2201110102 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" BTW, regarding 3) below, it looks like this is expected behavior from Clang/ LLVM. Dereferencing a NULL pointer is technically undefined in C, and by default the Clang optimizer will cause a trap to occur if you try to do it (because it assumes it's not safe for programs to do that). The flag -fno-delete-null-pointer-checks can be used to avoid this behavior. This flag seems to be valid for Clang 9 and later. This is slightly more efficient than using the volatile keyword to defeat the optimizer. This flag is also for GCC. -Bill > 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/OUTPU > T/ 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 =============================================================================