Re: [PATCH v2] ArmPlatformPkg/PrePeiCore: seed temporary stack before entering PEI core

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

On 5 November 2017 at 16:27, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 5 November 2017 at 05:52, Leif Lindholm <leif.lindholm@linaro.org> 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 <ard.biesheuvel@linaro.org>
>>
>> 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)