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

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

On 22 September 2016 at 11:06, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 22 September 2016 at 10:43, Pete Batard <pete@akeo.ie> 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