From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 E2BF91A1FB5 for ; Thu, 22 Sep 2016 14:21:45 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id r192so169806732ita.0 for ; Thu, 22 Sep 2016 14:21:45 -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=wm3fSPPVFH/IG2oxyLegLyXM51FBIBu0fTuLsDiqBa8=; b=iqiCAi08Hs39qQrktpWcc/wt4Mb0sDT9ncJRs8T2hiXFIaj2chhZtkWil4Agi1+J/E V/TtBWGUtJzytvKBK+tXvRkKjuMJIPhhEJXL1QBN2h/KsIJLHINTv4iyF6ApRFcFmoHy gT5iZx/kW8eaKIMBfYoWcaXC4b79f0DhgClmM= 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=wm3fSPPVFH/IG2oxyLegLyXM51FBIBu0fTuLsDiqBa8=; b=f28IFtk+kzJm8OTIoykQrLuiFOS+5Q7H2pOUaGEYDCQq7qWESR9gkFtetAzJaibvNM ZwFt4sWKWLiHxTiqrMFzlQQejqnZ7/ufWb3CtajNSjK/CAp8W31dzZCHya+Ldc4+iRzz w021MgkMFdNgy5I1guDfkzrrbZqS7WVR1oJKD3sBXxQqy4fpNI7iueTaI7CBTy3XwbcE SsidVm5wikpVLoaLGzMQ8G8KOk/ucN1dF3zBR6D8bQcrdw5kFwu/1F9j8Ppoy1i0JN/+ YXehQ69iU02o+giLL6eQ926h35mlUzO5OwykVWwXRqTzzdv3WSBpVaRb3veEVMCUDtkJ LkLw== X-Gm-Message-State: AE9vXwNZi5QPeXTowZXfmNNwtUqM35jyoFHkrd7KNXhPKIhXYbxPZ+1jpdOZqWoYoVJNGemRvGwXHh+I67GHa2ro X-Received: by 10.36.10.145 with SMTP id 139mr13598801itw.68.1474579305112; Thu, 22 Sep 2016 14:21:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Thu, 22 Sep 2016 14:21:44 -0700 (PDT) In-Reply-To: <418FE198-0CCC-4A8F-8C70-69BBF4E2EF05@apple.com> References: <88690c52-2185-13cb-2f61-eabedeb59b03@akeo.ie> <418FE198-0CCC-4A8F-8C70-69BBF4E2EF05@apple.com> From: Ard Biesheuvel Date: Thu, 22 Sep 2016 22:21:44 +0100 Message-ID: To: Andrew Fish Cc: Pete Batard , "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 21:21:46 -0000 Content-Type: text/plain; charset=UTF-8 On 22 September 2016 at 21:27, Andrew Fish wrote: > >> On Sep 22, 2016, at 4:05 AM, Pete Batard wrote: >> >> On 2016.09.22 11:06, Ard Biesheuvel wrote: >>> >>> 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. [...] >> Now, I'm not sure what the solution to that issue would be. I tend to agree >> that, short of including a parameter signature for function calls, this >> function argument marshalling issue between EBC and native will be difficult >> to solve. A possible half-workaround I thought of could be to keep track of >> all the PUSHes having been carried out before a CALLEX, and *assume* (or >> mandate in the specs) that all the arguments were pushed individually and >> that the size of the PUSH matches the desired size for a register argument, >> but even that would still add a lot of complexity and be prone to >> breakage... > > It seems like tracking the PUSHes would work? We could update the spec to > require this behavior. But it brings up another issue in that you don't know > how many PUSHes to go back? What is a calling convention PUSH vs. a state > save push? Maybe we could also add a max number of args that are supported? > Forcing the compiler to emit every function call as a series of in-order argument pushes may be overly restrictive, and only solves half of the problem. Native to EBC calls suffer from the same issue, and so we have to deal with this in the thunking layer. The EBC code already issues BRK instructions (IIRC) to call into the interpreter to generate the native to EBC thunks, so I think we should extend that mechanism to publish prototype annotations for all entry points subject to thunking (in either direction). The existing implementations for x86 could ignore these entirely, or perhaps use them to trim the size of the native to EBC stack copy (or vice versa). ARM would require these annotations (or perhaps only for prototypes where UINT64 arguments appear in odd positions) -- Ard.