From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 021261A1F43 for ; Thu, 22 Sep 2016 14:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1474579482; x=2338493082; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XSFtKzUr7tIivuxpKMAg/F1TMJYpa8kf1ITN8q74rpI=; b=Z+VJnQ5ZF9MP/HCVadGURWJAJEdHgsT9Pofl+5Jmj8bCH3sFJts6M7sN44dfF5G4 YYymUFAZsG6LKf6aOMwqkoPKF7UJud0UCHxxSFmZAxys8HBI1fqx1YDxNIphqwDo pZzOvzSQfpJTWbCfBu6PFFkcBxxUb2JRO5Inig/A7h96ZRywPJhMYZHE1iHsKYUQ vxDnahBMvhTdYD2Jd7MrOhy376/nHd4P1dQMAg2UodoaIzG1RUT8OTWu/2bA0dwi hT2HXs5TnpHeJr1IvIfSZU2EeNy4RX2l8T1Z7bTMx4vgogR0EONRsSy7QCDe/tOt IMNJrYfYwhHj4krDr424dQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id E9.40.17422.A1C44E75; Thu, 22 Sep 2016 14:24:42 -0700 (PDT) X-AuditID: 11973e16-f793f6d00000440e-24-57e44c1a0b86 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) by relay6.apple.com (Apple SCV relay) with SMTP id 14.BF.23613.91C44E75; Thu, 22 Sep 2016 14:24:41 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.85.100] by chive.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built May 17 2016)) with ESMTPSA id <0ODX009P9CT4AH40@chive.apple.com>; Thu, 22 Sep 2016 14:24:41 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: <8E1C407F-A3A7-47D8-B26D-4F2AD389B006@apple.com> Date: Thu, 22 Sep 2016 14:24:39 -0700 In-reply-to: Cc: Ard Biesheuvel , "edk2-devel@lists.01.org" To: Pete Batard References: <88690c52-2185-13cb-2f61-eabedeb59b03@akeo.ie> X-Mailer: Apple Mail (2.3226) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUi2FAYpSvl8yTcYO0qNov/H3YzWuw5dJTZ 4tiDNYwOzB4tU2eyedy5tofNo3v2P5YA5igum5TUnMyy1CJ9uwSujNm3nrAW/J7PWLHq4wTW BsZN7YxdjJwcEgImEh+XfoCyxSQu3FvPBmILCexllLgyM7aLkQOsZt0Pwy5GLqDwRkaJNe8e sILU8AoISvyYfI8FxGYWCJNYfmkWO0TRPUaJG1chioQFxCXendnEDGKzCShLrJj/gR1kKK+A jcT5s4oQJS4SR76eAZvDIqAqsfXxZrAbOAWsJb60nmOCmJ8q0dreCDZSREBO4uiEXYwQuzYx Skw8sJkF4lBZidm/vEDiEgL32SR2bvzONIFReBaSW2chuRXC1pL4/qgVKM4BZMtLHDwvCxHW lHh27xNUibbEk3cXWBcwsq1iFMpNzMzRzcwz10ssKMhJ1UvOz93ECIqb6XZiOxgfrrI6xCjA wajEw/vg8eNwIdbEsuLK3EOM0hwsSuK8f1SehAsJpCeWpGanphakFsUXleakFh9iZOLglGpg VCppnBy3zddb5aFtRo/Iq3Tnk92fQw9a+UhNj/N9Me9J1oQf03K/JTaZCa23fKfaxp7d8cea v/lCxaMvZ1/eeuFazNl/kW9bpYNi4IOfdlqm4W0cmq4fzrj9MRKV/3npVNCvHHHW7ku/5FNm PJPYKl9UYfC4a73E7lnXSz5OC1zyyHpT95vNSizFGYmGWsxFxYkAMrvLEXwCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsUi2FDMryvp8yTcoGGDjcX/D7sZLfYcOsps cezBGkYHZo+WqTPZPO5c28Pm0T37H0sAcxSXTUpqTmZZapG+XQJXxuxbT1gLfs9nrFj1cQJr A+OmdsYuRg4OCQETiXU/DLsYOYFMMYkL99azdTFycQgJbGSUWPPuAStIgldAUOLH5HssIDaz QJjE8kuz2CGK7jFK3LgKUSQsIC7x7swmZhCbTUBZYsX8D+wgC3gFbCTOn1WEKHGROPL1DNgc FgFVia2PN7OB2JwC1hJfWs8xQcxPlWhtbwQbKSIgJ3F0wi5GiF2bGCUmHtjMAnG0rMTsX14T GAVmITlvFpLzIGwtie+PWoHiHEC2vMTB87IQYU2JZ/c+QZVoSzx5d4F1ASPbKkaBotScxEoz vcSCgpxUveT83E2M4EAvjNrB2LDc6hCjAAejEg/vg8ePw4VYE8uKK3MPMUpwMCuJ8M5xexIu xJuSWFmVWpQfX1Sak1p8iHEiI9CTE5mlRJPzgXGYVxJvaGJiYGJsbGZsbG5iTkthJXHedbwP woUE0hNLUrNTUwtSi2COYuLglGpgNNv6fZVw73mrcLvqVPui7KoTvDH2R2NkvnHFcU7m/j35 X2q6No/J2YXWzTyi0SK79nPIZuVwqu91zzMQYbPYnVIn4TD3cYKakXxTcfYUVlfRfW3NMaty TVhYRJ8/rbMRedDFevmxdOl64bKH/n/DnLdVrr/3t81vX08ff1Nq2LbUyJ+92UosxRmJhlrM RcWJAF9EtBTnAgAA X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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:24:43 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > 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. > > I was hoping you would comment on this, as I believe the issue is larger than Arm (which is why I thought the Arm patch could be integrated), since I ran into something similar for X64 and AARCH64, with the conversion from stack to register parameters. > > Let me start by showing a real-life example of what the current EBC implementation does, on different architectures, if you CALLEX from EBC into a native function call such as: > > VOID MultiParamNative( > UINT32, > UINT64, > UINT64, > UINT64, > UINT32, > UINT32, > UINT64 > ); > Pete, Stupid question. Does adding EFIAPI fix this issue? So: VOID EFIAPI MultiParammNative( UINT32, UINT64, UINT64, UINT64, UINT32, UINT32, UINT64 ); I'm sitting next to Mike Kinney at the UEFI Forum Plug Fest and we were wondering if the calling convention stuff was mucked up on C side. Thanks, Andrew Fish > with values: > > 0x1C1C1C1C, > 0x2B2B2B2B2A2A2A2A, > 0x3B3B3B3B3A3A3A3A, > 0x4B4B4B4B4A4A4A4A, > 0x5C5C5C5C, > 0x6C6C6C6C, > 0x7B7B7B7B7A7A7A7A > > If you do that, then the parameter values seen by each Arch will be as follows: > > IA32: > p1 = 0x1C1C1C1C > p2 = 0x2B2B2B2B2A2A2A2A > p3 = 0x3B3B3B3B3A3A3A3A > p4 = 0x4B4B4B4B4A4A4A4A > p5 = 0x5C5C5C5C > p6 = 0x6C6C6C6C > p7 = 0x7B7B7B7B7A7A7A7A > > X64: > p1 = 0x1C1C1C1C > p2 = 0x3A3A3A3A2B2B2B2B > p3 = 0x4A4A4A4A3B3B3B3B > p4 = 0x5C5C5C5C4B4B4B4B > p5 = 0x6C6C6C6C > p6 = 0x7B7B7B7B > p7 = 0x06F23E4012345678 > > ARM: > p1 = 0x1C1C1C1C > p2 = 0x3A3A3A3A2B2B2B2B > p3 = 0x4A4A4A4A3B3B3B3B > p4 = 0x5C5C5C5C4B4B4B4B > p5 = 0x6C6C6C6C > p6 = 0x7A7A7A7A > p7 = 0x446EEC467B7B7B7B > > AA64: > p1 = 0x1C1C1C1C > p2 = 0x3A3A3A3A2B2B2B2B > p3 = 0x4A4A4A4A3B3B3B3B > p4 = 0x5C5C5C5C4B4B4B4B > p5 = 0x6C6C6C6C > p6 = 0x7B7B7B7B > p7 = 0x00000000FFFFFF91 > > Note that these are real-life results gotten from a native set of drivers [1] + EBC sample [2], specifically designed to test the above. > > So, as you can see, only IA32 currently retrieves the parameters with their expected values. All the other platforms, and not just Arm, have an issue with parameter retrieval. > > I too performed some analysis [3], to understand the problem, the result of which can be summarized as follows: > > Let's say you have native protocol function: > > ProtocolCall(UINT32, UINT64, UINT64) > > to which you want to pass values: > > (0x1C1C1C1C, 0x2B2B2B2B2A2A2A2A, 0x3B3B3B3B3A3A3A3A) > > With the EBC VM, the parameters then get stacked as (little endian, CDECL and using 32-bit longwords to represent the stack): > > +--------+ > |1C1C1C1C| > +--------+ > |2A2A2A2A| > +--------+ > |2B2B2B2B| > +--------+ > |3A3A3A3A| > +--------+ > |3B3B3B3B| > +--------+ > +????????+ > +--------+ > > Now, if you are calling into an x86_32 arch, this is no issue, as the native call reads the parameters off the stack, and finds each one it its expected location. > > But if, say, you are calling into native Arm, then the calling convention dictates that the first four 32 bits parameters must be placed into Arm registers r0-r3, rather than on the stack, and what's more, that if there exist 64 bit parameters among the register ones, they must start with an even register (r0 or r2). > > What this means is that, with the current EBC handling, which simply maps the top of the stack onto registers for native CALLEX (as the VM cannot guess the parameter signature of the function it is calling into, and therefore will not do anything else but a blind mapping of the stack onto registers), the native Arm function effectively gets called with the following parameter mapping: > > +--------+ > |1C1C1C1C| -> r0 (32-bit first parameter) > +--------+ > |2A2A2A2A| -> (r1/unused, since first parameter is 32-bit) > +--------+ > |2B2B2B2B| -> r2 (lower half of 64-bit second parameter) > +--------+ > |3A3A3A3A| -> r3 (upper half of 64-bit second parameter) > +--------+ > |3B3B3B3B| -> lower half of 64-bit third parameter (stack) > +--------+ > +????????+ -> upper half of 64-bit third parameter (stack) > +--------+ > > The end result is that, the Arm call ends up with these values: > > (0x1C1C1C1C, 0x3A3A3A3A2B2B2B2B, 0x????????3B3B3B3B) > > However, while we used Arm for this example, this is not an Arm specific issue, as x86_64 and Arm64 also expect any of the first eight parameters to a native call, that are smaller than 64-bit, to get passed as a 64-bit register, which means they too have the same issue as the one illustrated above. > > 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... > > The other solution of course is to ask EBC code developers to be aware of and compensate for the calling convention issue, and pad the stack as required depending on the ISA they are calling into, which is how I made my protocol.asm sample work [4], but this is still rather inconvenient, especially if not coding in EBC assembly, and defeats the point of trying to write Arch independent code. > > Considering this, I'm not entirely convinced ARM EBC integration should be held back, as the problem we are faced with is part of a larger issue that we'll need to resolve for all archs (except IA32), and not just ARM... > > Regards, > > /Pete > > [1] https://github.com/pbatard/fasmg-ebc/tree/master/Protocol > [2] https://github.com/pbatard/fasmg-ebc/blob/master/protocol.asm > [3] https://github.com/pbatard/fasmg-ebc/blob/master/protocol.asm#L113-L177 > [4] https://github.com/pbatard/fasmg-ebc/blob/master/protocol.asm#L211-L219 > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel