From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::244; helo=mail-it0-x244.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::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 153A52034EE1B for ; Sun, 5 Nov 2017 08:25:19 -0800 (PST) Received: by mail-it0-x244.google.com with SMTP id k70so2063780itk.0 for ; Sun, 05 Nov 2017 08:29:16 -0800 (PST) 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=UTym8qG2Xw7WmFIqxs4hEDn6jHUGBHzWPV6ozWdkEco=; b=YNqawpsi5Id16q/1Iz/rEb7L3HtZS4pxanbBHj7udfdsUBEwCNrFxdkKeG5/EIhSmj 3+0u28lgAHSpi4E051arCxcLjwP0WPrshUWvtAgEnMRzj/p+SjtXJ9ZnDXoJwNtif5PE GdVPmq3nI/qCf8oO+OBV0JauxL+Po8fuF7nF0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UTym8qG2Xw7WmFIqxs4hEDn6jHUGBHzWPV6ozWdkEco=; b=ahFs+BWPVHmcRgYMFPbwHgyKk3SS7PqkoHkW0LYNTnyPvIkt4p/GBn3JbBd6OptB70 +INKpSZ3wIibGDarNC8+LDU9H56+81y7sP1MHQUQCfsH1ykUTf6IHJV8o/lMW6fEIMjL 1FNxPQtL0FZxPcHBSDkkRCbJjJkCzjDVhuRY+N7ToHq0QS9GeIDRq33SAphJyogK11EQ x1tlvfW1y/PWbrY2DfiUcAetbqsZJuB5i3AU9FtEbvcg0kLKpe9vATyxtE/AdUlDEe4Y 4GfhuX59VxzSvKr0y6c0CQMOFacNF795KoCm20f1kVlhyIj14vLSpLBaLCeLfOhIeUL4 Fc1g== X-Gm-Message-State: AJaThX6dR3fRkDbXXCKq0BTcWPVp1rZXUCtKWToT2t3drP8UnKZ/3m6/ egQJEn2Wy4mtoOg4EF7fbDJB1giufIH6TqUaSx4biw== X-Google-Smtp-Source: ABhQp+TiXp9dTGsPIXLgftD7w4pa2keQij3agrslyt52XXHKiup1N0aRMmP0CuqQCH2u6uGZhHdrG27wn3Bc6xAu8Xs= X-Received: by 10.36.141.70 with SMTP id w67mr6281234itd.58.1509899355913; Sun, 05 Nov 2017 08:29:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.131.167 with HTTP; Sun, 5 Nov 2017 08:29:15 -0800 (PST) In-Reply-To: References: <20171103113352.8604-1-ard.biesheuvel@linaro.org> <20171105055245.xbicmlagfeu7xt2o@bivouac.eciton.net> From: Ard Biesheuvel Date: Sun, 5 Nov 2017 16:29:15 +0000 Message-ID: To: Leif Lindholm Cc: "edk2-devel@lists.01.org" , Laszlo Ersek , "Gao, Liming" Subject: Re: [PATCH v2] ArmPlatformPkg/PrePeiCore: seed temporary stack before entering PEI core X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 16:25:19 -0000 Content-Type: text/plain; charset="UTF-8" On 5 November 2017 at 16:27, Ard Biesheuvel wrote: > On 5 November 2017 at 05:52, Leif Lindholm wrote: >> On Fri, Nov 03, 2017 at 11:33:52AM +0000, Ard Biesheuvel wrote: >>> DEBUG builds of PEI code will print a diagnostic message regarding >>> the utilization of temporary RAM before switching to permanent RAM. >>> For example, >>> >>> Total temporary memory: 16352 bytes. >>> temporary memory stack ever used: 4820 bytes. >>> temporary memory heap used for HobList: 4720 bytes. >>> >>> Tracking stack utilization like this requires the stack to be seeded >>> with a known magic value, and this needs to occur before entering C >>> code, given that it uses the stack. Currently, only Nt32Pkg appears >>> to implement this feature, but it is useful nonetheless, so let's >>> wire it up for PrePeiCore as well. >>> >>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=748 >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Ard Biesheuvel >> >> OK, this may sound completely unreasonable, but seeing those >> implementations overwrite callee-saved registers without saving them >> makes my brain unhappy. (Yes, I know.) >> >> Could they either: >> - Have a comment prepended establishing the implicit ABI of which >> registers the caller cannot rely on reusing after return. >> Preferably somewhat echoed at the call site. >> - Be rewritten to use only scratch registers? >> > > I think it is implied that the startup code does not adhere to the > AAPCS. That code already uses r5 and r6 without stacking them, simply > because we're in the middle of preparing the stack and other execution > context, precisely so the C code we call into can rely on AAPCS > guarantees. Ehm, hold on, what do you mean by 'call site'? This code just runs and jumps back to a local label. There are no functions calls here until the point where we call into C (with the exception of the lovely ArmPlatformPeiBootAction() we added so Juno can find out how much DRAM it can use)