From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 BB0841A1FAE for ; Thu, 22 Sep 2016 14:40:32 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id 133so16215569wmq.2 for ; Thu, 22 Sep 2016 14:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akeo-ie.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=y67HJPW0Ec3dQ1LfMkLoCqQ20wLIUv5TyDM6+dGur8g=; b=WN+CoYE47BwG/9CiEPyDMjM7QdMxrEBzCN8fZdNA9wMArMvXXfTk7tauGDCGKl4yE+ k0kPZ1ZL75AAl7jqMLVOKn5iKBsm0XewUaHsTQLoBqLISUPmq56PXFJ1hGOco6YSjPQP ZjiJr45gubYIrurhwRF7HYVeY4r4HbTwRrP8ovMaWJzSVx4O0qTG8vmD+CJnluPtYOpi xsBs7U9Vg3n+8fx4Jo4vZBWpLEk2fJtKD4yXUQJNm0Fz9u0yFU7W+79MTMSzNiIk9Bm6 YMuilzXNh3RbhySNMgRdXkUVcwXnm73NDiPX8ZZxpWHEwyJyC4aUKpR240HhVXGQ2bBp AUIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=y67HJPW0Ec3dQ1LfMkLoCqQ20wLIUv5TyDM6+dGur8g=; b=f2lMoEC4F7WD4JoX+X+R+/pOs2d/0rL0Sj+XR48j82HOumqqKZG4IqFXvpy2/8w8UO awo63IcIkTF8QPs3Ii0KlF59DQfEDjzIUbNAaFgtXWOag5uvuDMAEfwFUWbqpC3Q8e6s FxQ9taCMsprM1p/8P4iKHT+18Sj5jRkJkSrGp29urxPcOgoIrHc5XWm+Pdr9VE6DfbVQ 8gJCIREarQ7/eHhzMbSJCnCJCY1NC2OY2FZLufPFMGLdKYm5kf7GnwWe9QaErBbvlAJQ illgjyUZPqwHEm0MBJLjNZ45TFRi4gXKxN1u+Y1ARvfwtfJy/tja6B6hJdDqiJlOkY3C +TRA== X-Gm-Message-State: AA6/9RmeOZt7TmjcOugj7phT6UiWgAV5sIG8FsF1tZYatMpOfl8UC0yyFOODCzUGcN2VIg== X-Received: by 10.28.212.9 with SMTP id l9mr4527471wmg.77.1474580431148; Thu, 22 Sep 2016 14:40:31 -0700 (PDT) Received: from [10.0.0.101] ([84.203.89.142]) by smtp.googlemail.com with ESMTPSA id w138sm354518wmd.1.2016.09.22.14.40.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Sep 2016 14:40:30 -0700 (PDT) To: Andrew Fish References: <88690c52-2185-13cb-2f61-eabedeb59b03@akeo.ie> <418FE198-0CCC-4A8F-8C70-69BBF4E2EF05@apple.com> Cc: Ard Biesheuvel , "edk2-devel@lists.01.org" From: Pete Batard Message-ID: <9313821b-b0f8-1548-838e-1d64dafb7bc0@akeo.ie> Date: Thu, 22 Sep 2016 22:40:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <418FE198-0CCC-4A8F-8C70-69BBF4E2EF05@apple.com> 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:40:33 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, On 2016.09.22 21:27, Andrew Fish wrote: > It seems like tracking the PUSHes would work? First of all, as got pointed out by Ard, I need to mention that much of my earlier analysis results, which you quoted, were due to a misread of the specs, as it does mandates pushing 32 bit parameters as native. So the output I gave for AARCH64 and X64 was erroneous, since it was a result of using PUSH32, and the problematic output disappears when using PUSHn. The only issue therefore, is with 32 bit ARM. > We could update the spec to require this behavior. If the idea is to add the tracking when processing POP/PUSH on Arm (which is how I originally saw it), please note that we may also have to track stack manipulation with MOV against R0, the EBC stack pointer, if someone issues something like 'MOV R0, R0(-1,0)' (equivalent to PUSHn) or 'MOV R0, R0(0,-8)' (equivalent to PUSH64) for some 32 or 64 bit optional parameter... However, this brings us back to our original issue if there exists a succession of optional 32 and 64 bit parameters, which the application doesn't care about filling, and that may be handled with a single 'MOV R0, R0(-1,-8)' in the assembly. If we are faced with this in our tracking, then we still have no way of knowing which of the 32 or 64 bit parameter comes first. So, notwithstanding other issues, we'd have to mandate something very specific against doing this in the UEFI/EBC specs (such as only using individual PUSHes)... Regards, /Pete