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::241; helo=mail-it0-x241.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 147402034EE1B for ; Sun, 5 Nov 2017 08:23:15 -0800 (PST) Received: by mail-it0-x241.google.com with SMTP id y15so2618814ita.4 for ; Sun, 05 Nov 2017 08:27:13 -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=j8Ml5guEWWpQ+YCFYvf41e3SnNqwgalJRVYEawZkw04=; b=Dc1ble+U/HW6VoiDP2i1joUPUaZsfpf2pJ/BU49oVfCdgBy8HArAxa8yuq+mJPFEZ9 i70AkWlYweUPaQzFN0xTTli4+IzUr2hmL2fC9LpGxtJ0tsbqHXl6XWng1O7QT8CIEiQ8 0kKgNS0vAT6rg3c/USc7F04fG0lSj4JFZyNKE= 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=j8Ml5guEWWpQ+YCFYvf41e3SnNqwgalJRVYEawZkw04=; b=MUgiDW3GRLCeOx03giYe4UmePoZh5U/RPMN6sP+i0oPB85XCi1vOK5btTWrtnHMi1U uQRDLukpoi9/Z3Ynzj3rKpc3fB7BZbp7m/L33RPv8/phDVaJ6RRG6tEoW7Wd4rE/dLYR HsBQf0VYwsrfo0SHDFVjYEtQgTvXR+JzmdEefPaPJLVnuGmdlv0jA6q5GBdyoVfESqNF 3gYDi96kRNskPSgyRJhacINYGSFl/obuvu8MetU7Mawjtei7r9NY2Y8mgTigpX4RF2tX dRENLDl+nBQ5gRTJ5sMhSbXWPZDRJKT9WMt2EwU4E5Yh+9pcK6ImenytNhNHo7kTaQ/V 0V5Q== X-Gm-Message-State: AJaThX7PH39wKUbd8CUj51Lfz+mADPgVbHXKvOMjlT/yUefGhplbXVs7 TD/NznOPmcWaDrizAjuOGvOCHvMI2d4oLzIrQMUwMw== X-Google-Smtp-Source: ABhQp+SvCCvG8ikgXNQxlS07CrQJIr3g0U63aD3kDFYL6v/bOTATiFOSshfUf+vmDDV6vjNgcWAe0ck98jlZQOrMQtE= X-Received: by 10.36.233.133 with SMTP id f127mr6361641ith.34.1509899232539; Sun, 05 Nov 2017 08:27:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.131.167 with HTTP; Sun, 5 Nov 2017 08:27:12 -0800 (PST) In-Reply-To: <20171105055245.xbicmlagfeu7xt2o@bivouac.eciton.net> References: <20171103113352.8604-1-ard.biesheuvel@linaro.org> <20171105055245.xbicmlagfeu7xt2o@bivouac.eciton.net> From: Ard Biesheuvel Date: Sun, 5 Nov 2017 16:27:12 +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:23:16 -0000 Content-Type: text/plain; charset="UTF-8" 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.