From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 976C51A1F43 for ; Thu, 22 Sep 2016 03:13:55 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id m186so80491180ioa.2 for ; Thu, 22 Sep 2016 03:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/nTJct1Xjjxi69+QPruEuaNY4jhXpcT9DYE8Harp06c=; b=IkvFng8nwuQmaouNgLJjvmQM5/x6ieh/rDB75BuXpULoPLsvRnJ5RZ1GsHvejN2gt9 UpLHbT/QDzvNNgyRMJkOke2eWZXsB9687AcsCLgeaVy0+qvgGGY/hJmcp2+/dROGVETz eNL2c89tDRMqJ7ipqpin/kMplyzkxSUSuhs3M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/nTJct1Xjjxi69+QPruEuaNY4jhXpcT9DYE8Harp06c=; b=HN/9hg7T4xZLW4X9RZ3q0ATxUDprvmcYWqutZ/RNMUhZ1aguOiiPzCvuVr1VkTZNrJ hEYsmsdjAeFBU7GFLaPpRVgWbDWh899GG2lLcuSW+jEeaCn9+viwwdnbpi4Kz7ZdO6cc D54omnOrYZi6OI4gJb/aR3TLwO7nhWJ25hvtllnyRE7Rx73J+CTXObU1B1MSP13qegYU nTbLQ5/eCTq485s41IEXTV0YjhWs4UogoA/a4hpajea+AMRC/x5wfLDfowagOPlnV63X gehlVYHiGWnPULwr2dM/rzumgn99Oj+DP3Ri76tE35geCQuLVjFzn2P2stb0gJK9sJ2V Nu7w== X-Gm-Message-State: AE9vXwOw28PJ4p94EuzhPDRSsMLg5i+uk+NRpXNY/ov3N9kSNMFSg6BXZZqtZFE2T960Lht70eEYUbnMR3qO+qms X-Received: by 10.107.190.68 with SMTP id o65mr1814574iof.95.1474539234881; Thu, 22 Sep 2016 03:13:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Thu, 22 Sep 2016 03:13:54 -0700 (PDT) In-Reply-To: References: <88690c52-2185-13cb-2f61-eabedeb59b03@akeo.ie> From: Ard Biesheuvel Date: Thu, 22 Sep 2016 11:13:54 +0100 Message-ID: To: Pete Batard Cc: "edk2-devel@lists.01.org" Subject: Re: [PATCH 0/1] MdeModulePkg/EbcDxe: add ARM support 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, 22 Sep 2016 10:13:55 -0000 Content-Type: text/plain; charset=UTF-8 On 22 September 2016 at 11:06, Ard Biesheuvel wrote: > On 22 September 2016 at 10:43, Pete Batard wrote: >> Hi, >> >> The following is an updated/fixed version of the patch(es), put forward by >> Ard Biesheuvel on August 9 ([1], [2]), and re-submitted for formal >> inclusion, so that the EDK2 can provide EBC functionality for all of IA32, >> IA64, X64, AARCH64 and ARM at last. >> >> This updated patch now includes the necessary corollary dsc/fdf updates as >> well as fixes to the assembly's EbcLLCALLEXNative, as I found the following >> issues there: >> - At least gcc5 didn't seem to like the manually optimized branching for all >> register args ("sub r1, r1, r3, lsr #1"), and one can never be sure of the >> actual size instructions will be assembled into, in case of assembler >> internal alignment/optimization, so I broke it down into actual labelled >> branches. There are only 4 of those anyway. >> - For register + stack calls, while 8 x 64 bit registers on AARCH64 do >> equate to #64 bytes that need to be taken off the stack, on ARM the 4 x 32 >> bit registers equate to #16 bytes, not #32 >> - Even after fixing the above, I found some issues with the manual stack >> duplication assembly code, so I switched to using a call to CopyMem(), like >> IA32 does. >> >> With these changes, I believe that the ARM/EBC feature should be fully >> functional, especially as I have heavily tested multiparameter calls from >> EBC into native, using an fasmg-based EBC assembler [3], to confirm that >> they performed just as well with ARM as with AARCH64, IA32 or X64. >> > > Hello Pete, > > Thanks a lot for this contribution. I had spotted (and fixed) some of > the above issues as well. > > However, there is a fundamental issue with EBC on ARM that has not > been addressed yet, which makes EBC support problematic: > ARM uses natural alignment for 64-bit types, which means it leaves > gaps in the stack frame, and the thunking code has no way of dealing > with that. > > I am pasting my analysis below, which I sent out internally a couple > of weeks ago. In summary, we need language spec and compiler updates > before we can fully support this on 32-bit ARM. > BTW, the EDK2 tree has an EBC version of the FAT filesystem driver, which is what I have been using to test EBC. I have a Frankenstein version of the 32-bit ARM one (shared below) that deals with the padding of known protocol methods that contain UINT64 arguments at odd positions, but it is not pretty, and a clear example why the spec needs to be updated to accommodate ARM https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/ebc3