[x86/Linux] Fix constructor missing in UnmanagedToManagedFrame

[seanshpark]

Fix compile error for x86/Linux

• full error string: constructor for 'UMThkCallFrame' must explicitly
  initialize the base class 'UnmanagedToManagedFrame' which does not
  have a default constructor
• wrap UMThkCallFrame with also !FEATURE_PAL

[seanshpark]

@dotnet-bot test CentOS7.1 x64 Debug Build and Test please

[janvorli]

@jkotas - why are the reverse PInvoke stubs different for x86 and the other architectures? Should the x86 Linux be on this plan too?
The doc in frames.h says:

Reverse P/Invoke (used for C++ exports & fixups as well as delegates
obtained from function pointers):
Normal stub:
x86: The stub is generated by UMEntryThunk::CompileUMThunkWorker
(in DllImportCallback.cpp) and it is frameless. It calls directly
the managed target or to IL stub if marshaling is required.
non-x86: The stub exists statically as UMThunkStub and calls to IL stub.
Prestub:
The prestub is generated by GenerateUMThunkPrestub (x86) or exists statically
as TheUMEntryPrestub (64-bit), and it erects an UMThkCallFrame frame.

But it doesn't explain why.

[jkotas]

Historic reasons. x86 went through like 3 very different implementations of interop and there are still some wounds from it. Non-x86 platforms were always on the pure stubs-as IL plan.

We can go either way for Linux x86 (make it work like Win x86 vs. make it work like non-x86 platforms). Making it work like non-x86 platforms will likely require designing and typing more code, but may be cleaner at the end.

The same goes for exception handling. I see that the other commits are working towards making it work like non-x86 platforms on Linux - will likely require designing and typing more code, but may be cleaner at the end.

[janvorli]

@jkotas thank you for the details. I would prefer moving towards the non-x86 platforms here.
@seanshpark, instead of the current change, could you please ensure that all definitions and usages of the UMThkCallFrame are ifdefed out for FEATURE_PAL? It will likely have some additional ripple effect.

[seanshpark]

UMThkCallFrame are ifdefed out for FEATURE_PAL?

OK and thank you @janvorli , @jkotas. I've little understanding about moving towards the non-x86 platforms so may take some time or do some stupid things. Please guide me with patience :)

[seanshpark]

@dotnet-bot test Windows_NT x86 legacy_backend Checked Build and Test please

[seanshpark]

@dotnet-bot test FreeBSD x64 Checked Build please

[RussKeldorph]

Please ignore the x86 compatjit and x86 legacy_backend job failures. They have been removed from future PRs.

[janvorli]

I can also see the UMThkCallFrame used in GenerateUMThunkPrestub in cgenx86.cpp. I think we need to comment the method out for FEATURE_PAL (both here and in the dllimportcallback.h) and also modify ifdefs around the place it is used in prestub.cpp.
And the same for the g_UMThunkPreStub variable.
Later we will need to create the TheUMEntryPrestub asm helper for i386, but that will come after we fix all the build issues.

[seanshpark]

@janvorli , could you please look this again?

[janvorli]

LGTM, thank you!