| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- cbz/cbnz destination must be after the instruction.
In our case, an overflow occurs and it jumps into unknown place.
Signed-off-by: Petr Bred <bredpetr@gmail.com>
|
|
- the bug occurred when we jumped into __tls_get_addr,
it overwrites our LR register.
Signed-off-by: Petr Bred <bredpetr@gmail.com>
|
|
|
|
|
|
Merge nmirror to master
|
|
[tfs-changeset: 1670378]
|
|
|
|
`FastAllocateString` (the choke point through which all string allocations go through) wasn't as fast as it could be and we were 30% slower than CLR on allocating strings. We were leaving a lot of perf on the table.
Before this change, string allocation was using the same allocator as arrays. Since there's a subtle difference between the failure modes on overflow (string allocation throws OOM, array allocation throws OverflowException), `FastAllocateString` required a try/catch block to handle the corner case. This was inhibiting codegen optimizations around this code path - to fix that problem, we needed a separate allocator. And since we now had a separate allocator for strings, I also took the liberty of inlining some details around strings (component size and base size) into the helper. It turns out runtime already hardcodes the details around strings (the component size) in a couple places anyway, so this is not that big of a "separation of concerns" violation as it looks like.
[tfs-changeset: 1670224]
|
|
|
|
|
|
* [armel tizen] Implemented InteropThunksHelpers.S stubs
* Saved floating point arg register
|
|
|
|
|
|
|
|
* [arm linux] Provided asm stubs for ExceptionHandling.S & CallingConventionConverterHelpers.S
* Synced UNHIJACK part of RhpThrowEx with arm windows version
* Fixed asm version of RhpNewFast
* Added CallingConventionConverter_SpecifyCommonStubData
|
|
|
|
Signed-off-by: Petr Bred <bredpetr@gmail.com>
|
|
[tfs-changeset: 1664997]
|
|
* [arm tizen] Implemented AllocFast.s stubs
* Rollbacked portable.cpp(from #3989)
* Added changes in CallDescrWorker.S
|
|
- correct access to tls global variable in arm thumb
Signed-off-by: Petr Bred <bredpetr@gmail.com>
|
|
Signed-off-by: Petr Bred <bredpetr@gmail.com>
|
|
|
|
Signed-off-by: Petr Bred <bredpetr@gmail.com>
|
|
Signed-off-by: Petr Bred <bredpetr@gmail.com>
|
|
|
|
MRT helpers
This change unifies StackFrameIterator behavior w.r.t. to special handling of various internal addresses within MRT helpers to the way I fixed this before for the UniversalTransitionThunk i.e. instead of exporting a public symbol in the middle of the method which is known to confuse the DIA stack unwinder, we export the pointer by means of an auxiliary data variable.
[tfs-changeset: 1661485]
|
|
|
|
Today our ProjectN images are not CFG-enabled, but CFG will kick in for applications that have CFG enabled, in particular, WWAHost (for JavaScript apps). Today with those apps and dynamic interop enabled we would trigger a CFG check as those thunks are never registered under CFG.
There are a couple of ways to achieve this. 1) You could take advantage of the CFG table which OS loader understands and would remap in MapViewOfFile. In order to make those thunks show up in CFG, you need to give them symbolic names. According to my testing, it only seem to work if we map the full mrt100_app.dll, which isn't ideal. 2) Use SetProcessValidCallTargets and supply the thunks. I went with SetProcessValidCallTargets, which works, but has its own set of challenges (if we discover that OS matrix we need to support with CFG becomes unsustainable with this approach we can revisit):
1. Our ARM test environment is on 8.1, while SetProcessValidCallTargets is Win10+.
Normally you would fix this by either 1) LoadLibrary/GetProcAddress or 2) delay loading. Unfortunately none of these work today because LoadLibrary is not part of WACK (and has a non-trivial cost to support) and 2) SetProcessValidCallTargets is on kernel32 and not delay loadable.
Fortunately there is a API set available load api-ms-win-core-memory-l1-1-3.dll which will has this API. It is effectively forwarded to kernelbase.dll but for the purpose of delay loading it works perfectly. When the API is not found, we would redirect the API to a predefined failure stub that simply returns true.
It is worth noting that if we opt to use LoadLibrary/GetProcAddress (which you can't do under UWP), calling SetProcessValidCallTarget would trigger CFG check as it is declared __declspec(guard(nocf)) for security reasons. Fortunately delay loading works fine.
2. Calling SetProcessValidCallTargets would fail on non-CFG-enabled processes. This can be fixed by calling GetProcessMitigationPolicy to determine whether the process is CFG-enabled.
3. SetProcessValidCallTargets require our thunks to be 0x10 aligned. x64/ARM is already 0x10 aligned but x86 is only aligned on 0x4. This means we'll need to waste 0xc for each thunk on x86. This a bit unfortunate but I doubt anyone would care. If this ends up wasting too much space we can revisit and optimize as needed.
4. SetProcessValidCallTargets is not allowed in WACK today. Fortunately it is already on pre-approved WACK list for RS2. It does mean that you won't be able to submit apps with mrt100_app.dll today but that's probably fine - our plan for the new toolchain is RS3+.
5. Our toolsets in razzle enlistment only has 8.1 the latest. For now I've work arounded by manually declaring the imports and copy the latest mincore.lib to rh/public/minwin folder. This has a unfortunate side effect that it also 'upgrades' RaiseFailFastException to a new API set that is not available down-level 8.1. I've made RaiseFailFastException also delay loading so that we wouldn't immediately fail to load under ARM + Win 8.1. I doubt any one cares about how N failfast under 8.1.
6. Similarly, ToF also has a copy of Win8 toolset in its own ExternalAPI (not the razzle one) and it doesn't support creating a CFG-aware binary. One possiblity is to use JavaScript app like in the bug, but you also need a reliable way to construct thunks and send it over to javaScript as v-table so that JavaScript can call it. This is basically dyanmic interop feature so the best way to cover this today without CFG-aware toolset is in dyanmic interop testing with full dyanmic interop mode on (everything dynamic). Once we have a CFG-aware toolset (I suspect this would only happen when we move out of ToF), we can have the main C++ app call reverse p/invoke thunks.
I've introduced a new API PalMarkThunksAsValidCallTargets to do the heavylifting - to allocate the correct data structure ro register the thunks and call SetProcessValidCallTargets. Rest of the stuff are less interesting.
After this change, I've verified the Yahoo app with dynamic interop turned on can proceed further (but still eventually timed out). I've also done a few more testing:
* ARM 8.1 private interop run,
* x86 private interop run,
* thunkpool tests
* x86chk precheckin
* verified ARM phone does have SetProcessValidCallTargets API.
* Build and ran all CoreRT tests
[tfs-changeset: 1655595]
|
|
Native
This change unifies the runtime delegate marshalling infrastructure between CoreRT and .NET Native by removing duplicate codes and moving shared helpers to PInvokeMarshal in CoreLib. I got rid of the InteropThunskHelpers from Interop.Native directory and instead used the ones already ported to CoreRT. With this unification the delegate marshalling memory leak issue(which was caused by not having a cache) should be gone.
[tfs-changeset: 1654801]
|
|
According to recent findings current Windows DIA stackwalker malfunctions at the address ReturnFromUniversalTransition_DebugStepTailCall because it misinterprets the label for the beginning of a new method and assumes that RSP / ESP points to the return address. As the ingestion of an updated DIA version is a longer-term process I'm proposing to temporarily fix this by exporting a temporary variable holding the return address instead.
[tfs-changeset: 1653716]
|
|
[tfs-changeset: 1653409]
|
|
cross compiling (#2793)
* Passing target platform&os to IlcCompiler
* Deleted /sys/devices/system/cpu/cache parsing
* Added empty version of InteropThunksHelpers for arm
|
|
Initital support for delegate marshalling.
- Enabled only in full runtime
- Doesn't work in non-windows platforms
- Only supports open static delegates
|
|
|
|
|
|
|
|
Merge nmirror to master
|
|
Handling of hardware exceptions had a hack to add +1 to the actual instruction IP. Windows x64 unwinder
is disassembling instructions at the IP passed in to detect method epilogs. If the bytes at IP + 1
happened to match the epilog pattern, the unwind is done as if we were in the middle of the epilog that
lead to spectacular crash.
This change is moving this adjustment to be done later for EH related things only, and not interfere
with stackwalking.
Fixes #2535
[tfs-changeset: 1645602]
|
|
|
|
CoreRT, and adding all the conversion helper stubs
|
|
This change fixes the performance of the interface resolving on ARM32 that was made worse by my previous fix of a bug in that area. Now the performance is back at the same level as before my change.
[tfs-changeset: 1641570]
|
|
RhpCastableObjectDispatchHelper is jumped-to from RhpInterfaceDispatchX functions. The RhpInterfaceDispatchX were not preserving r12 on ARM / eax on x86 that contain the address of the indirection cell, which lead to failures.
The fix is to let RhpCastableObjectDispatchHelper accept the cache entry pointer in r12 / eax instead.
I have also updated the CastableObject.cs based on Fadi Hanna's suggestion so that it can catch the issue this change fixes.
[tfs-changeset: 1641040]
|
|
[tfs-changeset: 1640866]
|
|
_RhpCastableObjectDispatchHelper is jumped-to from RhpInterfaceDispatchX functions. The RhpInterfaceDispatchX were not preserving r12 on ARM / eax on x86 that contain the address of the indirection cell.
[tfs-changeset: 1640787]
|
|
allocated dynamically in memory using VirtualAlloc. The thunk stubs pages are marked with RX permissions and the thunks data pages are marked with RW permissions.
Refactored some code in ThunkPool.cs to remove from it any knowledge about the thunk sections layout. Thunks layout and allocation become a black box to ThunkPool.cs. All the section layout information is moved to the native component, and section navigation is done by calls to some APIs.
The dynamically allocated thunks pages are enabled by a FEATURE_RX_THUNKS, and only in CoreRT's Full build for now. The portable build doesn't yet support thunks.
[tfs-changeset: 1638131]
|
|
Removing the hardcoded number, and making it into a function call.
[tfs-changeset: 1636433]
|
|
1) Removing the ThunkPool APIs from the System.Private.Corelib layer and moving it to mrt100_app.dll. Reasons:
a) A more correct layering
b) Thunks are also used by mrt100_app, and today it has to call into the S.P.Corelib layer to get thunks
c) The binder (which today takes care of laying out the thunks section) is going away with the ProjectX work, so the refactoring is needed
2) Addition of a new API: CreateThunksHeap. Thunks are allocated and deallocated from heaps, and each caller can create and managed their own heaps (TODO: heap deallocation feature)
Note: The use of a simple heap removes the need for a the hashtable that we previously had in the old implementation, and simplifies the implementation a bit.
4) Optimization (use of simple thunks linked list with better perf characteristics)
5) Added ThunkPool APIs into the internal RuntimeAugments assembly, to enable writing of tests that directly target the thunks APIs
6) Tests for the feature (including a multithreaded test).
Tested on all 3 architectures.
[tfs-changeset: 1634032]
|
|
RhpLoopHijack is called in a call chain of RhpGcStressProbe. This can happen during GC stress when GC calls GCToEEInterface::GcStartWork, which calls RestrictedCallouts::InvokeGcCallouts and that calls managed System::Runtime::InteropServices::RCWWalker.OnGCStarted, where there is a loop with with injected RhpLoopHijack down the call chain.
[tfs-changeset: 1633416]
|
|
opcode (or similar), which end up resolving interface methods using the RhpResolveInterfaceMethod API.
[tfs-changeset: 1632820]
|
