Re: [PATCH 0/1] MdeModulePkg/EbcDxe: add ARM support

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 22 September 2016 at 21:27, Andrew Fish <afish@apple.com> wrote:
>
>> On Sep 22, 2016, at 4:05 AM, Pete Batard <pete@akeo.ie> 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.