| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
While making the ready to run tests run on Unix, I have discovered that the feature
doesn't really work on Unix. First, I have found that the test was generating the
native images into the NI subfolder, but the corerun on Unix doesn't use this
notation and expects these images to live side by side with the IL executables.
So, the test to verify that an image cannot be loaded multiple times was failing,
since the main exe loaded the IL test.dll instead of the native one and so explicit
load of the native test.dll wasn't considered a secondary load of the same image.
After fixing the test, I have found that attempt to load a ready to run image is
failing with an assert.
There were these issues:
- the loaded native image was not marked as relocated
- the EPILOG_WITH_TRANSITION_BLOCK_RETURN macro was missing popping argument registers
- One of the asserts and one getter didn't take into account the fact that the ready to
run native image is not considered to have native header.
- The assembler helpers DelayLoad_Helper and DelayLoad_MethodCall were passing a hex
number as a parameter to the PROLOG_WITH_TRANSITION_BLOCK, but it was using the "h"
suffix notation. There is a known issue in the clang assembler which causes such
suffix to be swallowed so the macro was getting just "10" instead of "10h". The fix
was to use 0x prefix instead.
This change fixes the problem. The ready to run tests pass with it correctly.
|
|
|
|
This change enables building the ReadyToRun feature on Unix systems.
|
|
On x64, Linux uses rsi instead of rdx to pass the second parameter.
|
|
The Unix asm stubs had personality routines that were the windows personality
routines. This was incorrect since the signature of the Unix ones is completely
different. Moreover, some of these personality routines were not necessary
on Unix at all and two of them should dump the stack and terminate the process
instead of the handling that was necessary on Windows.
Finally, I've fixed an issue in the HandleHardwareException that contains
_ASSERTE in case the hardware exception was unhandled. But _ASSERTE contains
a debugger break instruction, which in the absence of the debugger invokes
the HandleHardwareException again. So I've added detection of the
breakpoint.
|
|
StubDispatchFixupStub for UNIX
|
