summaryrefslogtreecommitdiff
path: root/Documentation/botr
diff options
context:
space:
mode:
authorJiyoung Yun <jy910.yun@samsung.com>2016-12-27 16:46:08 +0900
committerJiyoung Yun <jy910.yun@samsung.com>2016-12-27 16:46:08 +0900
commitdb20f3f1bb8595633a7e16c8900fd401a453a6b5 (patch)
treee5435159cd1bf0519276363a6fe1663d1721bed3 /Documentation/botr
parent4b4aad7217d3292650e77eec2cf4c198ea9c3b4b (diff)
downloadcoreclr-db20f3f1bb8595633a7e16c8900fd401a453a6b5.tar.gz
coreclr-db20f3f1bb8595633a7e16c8900fd401a453a6b5.tar.bz2
coreclr-db20f3f1bb8595633a7e16c8900fd401a453a6b5.zip
Imported Upstream version 1.0.0.9127upstream/1.0.0.9127
Diffstat (limited to 'Documentation/botr')
-rw-r--r--Documentation/botr/README.md (renamed from Documentation/botr/_tableOfContents.md)0
-rw-r--r--Documentation/botr/clr-abi.md6
-rw-r--r--Documentation/botr/exceptions.md12
-rw-r--r--Documentation/botr/garbage-collection.md2
4 files changed, 15 insertions, 5 deletions
diff --git a/Documentation/botr/_tableOfContents.md b/Documentation/botr/README.md
index db4ffc121c..db4ffc121c 100644
--- a/Documentation/botr/_tableOfContents.md
+++ b/Documentation/botr/README.md
diff --git a/Documentation/botr/clr-abi.md b/Documentation/botr/clr-abi.md
index cbd5fc903c..caa5c7add9 100644
--- a/Documentation/botr/clr-abi.md
+++ b/Documentation/botr/clr-abi.md
@@ -6,6 +6,8 @@ It describes requirements that the Just-In-Time (JIT) compiler imposes on the VM
A note on the JIT codebases: JIT32 refers to the original JIT codebase that originally generated x86 code and was later ported to generate ARM code. Later, it was ported and re-architected to generate AMD64 code (making its name something of a confusing misnomer). This work is referred to as RyuJIT. RyuJIT is being ported to generate ARM64 code. JIT64 refers to the legacy codebase that supports AMD64.
+CoreRT refers to https://github.com/dotnet/corert runtime that is optimized for AOT. The CoreRT ABI differs in a few details for simplicity and consistency across platforms.
+
# Getting started
Read everything in the documented Windows ABI.
@@ -289,6 +291,8 @@ On ARM and ARM64, for all second pass funclets (finally, fault, catch, and filte
Catch, Filter, and Filter-handlers also get an Exception object (GC ref) as an argument (`REG_EXCEPTION_OBJECT`). On AMD64 it is the second argument and thus passed in RDX. On ARM and ARM64 this is the first argument and passed in R0.
+CoreRT does not use PSPSym. For filter funclets the VM sets the frame register to be the same as the parent function. For second pass funclets the VM restores all non-volatile registers. The same convention is used across all platforms.
+
(Note that the JIT64 source code contains a comment that says, "The current CLR doesn't always pass the correct establisher frame to the funclet. Funclet may receive establisher frame of funclet when expecting that of original routine." It indicates this is the reason that a PSPSym is required in all funclets as well as the main function, whereas if the establisher frame was correctly reported, the PSPSym could be omitted in some cases.)
## Funclet Return Values
@@ -468,7 +472,7 @@ Filters are invoked in the 1st pass of EH processing and as such execution might
Duplicated clauses are a special set of entries in the EH tables to assist the VM. Specifically, if handler 'A' is also protected by an outer EH clause 'B', then the JIT must emit a duplicated clause, a duplicate of 'B', that marks the whole handler 'A' (which is now lexically disjoint for the range of code for the corresponding try body 'A') as being protected by the handler for 'B'.
-Duplicated clauses are not needed for x86.
+Duplicated clauses are not needed for x86 and for CoreRT ABI.
During exception dispatch the VM uses these duplicated clauses to know when to skip any frames between the handler and its parent function. After skipping to the parent function, due to a duplicated clause, the VM searches for a regular/non-duplicate clause in the parent function. The order of duplicated clauses is important. They should appear after all of the main function clauses. They should still follow the normal sorting rules (inner-to-outer, top-to-bottom), but because the try-start/try-end will all be the same for a given handler, they should maintain the ordering, regarding inner-to-outer, as the corresponding original clause.
diff --git a/Documentation/botr/exceptions.md b/Documentation/botr/exceptions.md
index daa684bf8b..8e4b77a051 100644
--- a/Documentation/botr/exceptions.md
+++ b/Documentation/botr/exceptions.md
@@ -278,10 +278,16 @@ To use the callout filter, instead of this:
write this:
BOOL OneShot = TRUE;
-
- PAL_TRY
+ struct Param {
+ BSTR* pBSTR;
+ int length;
+ };
+ struct Param param;
+ param.pBSTR = pBSTR;
+
+ PAL_TRY(Param*, pParam, &param)
{
- length = SysStringLen(pBSTR);
+ pParam->length = SysStringLen(pParam->pBSTR);
}
PAL_EXCEPT_FILTER(CallOutFilter, &OneShot)
{
diff --git a/Documentation/botr/garbage-collection.md b/Documentation/botr/garbage-collection.md
index 9e16131114..789c4e92ff 100644
--- a/Documentation/botr/garbage-collection.md
+++ b/Documentation/botr/garbage-collection.md
@@ -2,7 +2,7 @@ Garbage Collection Design
=========================
Author: Maoni Stephens ([@maoni0](https://github.com/maoni0)) - 2015
-Note: See the The Garbage Collection Handbook referenced in the resources section at the end of this document to learn more about garbage collection topics.
+Note: See _The Garbage Collection Handbook_ (referenced in the resources section at the end of this document) to learn more about garbage collection topics.
Component Architecture
======================