[x86/Linux] Get Frame Pointer from CallerSp

[parjong]

GetGSCookieAddress uses pEbp to get the current frame pointer, but pEbp
is not properly initialized as discussed in #8980.

This commit revises GetGSCookieAddress to use CallerSp (as in other
architectures) to get Frame Pointer in order to fix #8980.

[parjong]

\CC @seanshpark @wateret

[parjong]

To resolve #8980, #9232 is required in addition to this PR.

[janvorli]

It is still unclear to me how come the pEbp (or pCurrentContext->Ebp in the new world) is not initialized. Looking at the code and the callstack you have dumped in the other issue, it seems that the FillRegDisplay should set it and that it should be called on that code path.
Actually, now that I think about it again, I think that the problem was due to the issue with the context pointers ordering that you've fixed today - we were setting the Ebp context pointer to point to Eax in the context.
So I think it is likely that this change is not needed anymore.

[parjong]

@janvorli I tested whether #9121 resolves #8980, but unfortunately it turns out that #9121 is not enough.

As discussed in #8981, the context pointers that EECodeManager::GetGSCookieAddr takes points to the caller's frame (not the current frame), and thus #9121 will result in the following assertion failure:

Assert failure(PID 2276 [0x000008e4], Thread: 2276 [0x08e4]): !"About to FailFast. set ComPlus_AssertOnFailFast=0 if this is expected"
    File: /home/parjong/projects/dotnet/coreclr/src/vm/jithelpers.cpp Line: 5710
    Image: /home/parjong/projects/dotnet/dotnet-overlay/Linux.x86.Debug.Debug/corerun

[janvorli]

Ah, I have remembered it wrong then. I have thought the problem was that the pEbp was garbage. The change makes sense then.

[janvorli]

LGTM, thank you!