[x86/Linux] Generate conservative epilog

[parjong]

ESP may be variable when UNIX_X86_ABI is used, and incorrect ESP (especially resuming from exception) causes various issues such as JIT.IL_Conformance.Old.Conformance_Base.conv_ovf_r8_i test failure.

This commit attempts to insert SP-restore instruction in function epilog to fix such issues.

[parjong]

\CC @seanshpark

[parjong]

This PR seems to resolve #9272, too.

[jkotas]

If you run with wrong SP, the GC reporting will be wrong. Fixing up the SP in epilog may hide the problem for the situation you are seeing; but I expect that it will lead to much harder to debug crashes later.

[parjong]

@jkotas I am also trying to revise unwinder (#9384), but it seems that stack-align padding will cause incorrect SP issue even with correct unwinder.

[parjong]

@jkotas I guessed that GC will refer each object via ebp instead of esp, but your comment suggests that there is a case that GC uses esp to refer each object.

Could you let me know where related implementation is? I would like to analyze that issue, but GC is too large to analyze. It will be very helpful if you could provide any hint for GC issue.

[jkotas]

This is not really in the GC. It is in the handshake between the JIT and CodeManager.

The JIT generates the GCInfo reporting against SP in some cases, and then the CodeManager does reporting against SP accordingly. It is done in multiple places, for example here: https://github.com/dotnet/coreclr/blob/master/src/vm/eetwain.cpp#L4488 .

Anyway, running with bad ESP and then try to compensate for it is a bad idea. It will create endless problems.

[stephentoub]

@dotnet-bot test this please (Jenkins was down)

[parjong]

@dotnet-bot test Windows_NT x64 Release Priority 1 Build and Test please

[parjong]

@jkotas Here is an simple example of this issue:

PROLOG:
push ebp
mov esp, ebp
MAIN:
sub esp, PAD
push arg_N
...
push arg_0
call func
add  esp, PAD
EPILOG:
pop ebp
ret

The current unwinder sometimes provides the state before call func, but will be revised to provide the state after call func (ESP is correct in some sense).

When we resume execution from EPILIOG after handling a managed exception throw from func, however, EE will resume the execution using the state just after call func not after add esp, PAD (even after unwinder is revised).

Do you mean that unwinder should take care of such padding?

[jkotas]

When we resume execution from EPILIOG after handling a managed exception throw from func

What will happen if there is more code in the given method after the try/catch that you are resuming from? Won't you be potentially a lot of code with bad SP?

Do you mean that unwinder should take care of such padding?

I think so. Resume after caught exception has to use correct SP.

[parjong]

Hmm.. the code related with compiler->compLocallocUsed indicates that we will encounter similar issues when there is localloc, but seems to work currently. Could you let me know if there is some workaround related with localloc?

[jkotas]

The GC info is careful about using BP-relative or SP-relative offset for each value. The two are not interchangeable. Pending arguments are reported SP-relative, for example. Reporting them BP-relative would not work in methods with localloc or funclets.

but seems to work currently

Have you done any stress testing on it? The subtle GC reporting issues only show up once you start running large programs; or under targeted stress...

[parjong]

@jkotas x86/Linux is still under bring up, and GCstress test is not performed, yet (but it is definitely required).

[parjong]

I'll take a look at how GC will work, and re-open PR when ready.