.c. These trampolines differ from the normal ones because they receive the PC address of the throw site, instead of a displacement from the start of the method. See exceptions-amd64.c for an example.
+- Implement the resume_unwind () trampoline, which is similar to the throw trampolines, but instead of throwing an exception, it should call mono_resume_unwind () with the constructed MonoContext.
+
+LLVM problems
+-------------
+
+Here is a list of problems whose solution would probably require changes to LLVM itself. Some of these problems are solved in various ways by changes on the LLVM Mono branch.
+
+- the llvm.sqrt intrinsic doesn't work with NaNs, even through the underlying C function/machine instruction probably works with them. Worse, an optimization pass transforms sqrt(NaN) to 0.0, changing program behaviour, and masking the problem.
+- there is no fabs intrinsic, instead llc seems to replace calls to functions named 'fabs' with the corresponding assembly, even if they are not the fabs from libm ?
+- There is no way to tell LLVM that a result of a load is constant, i.e. in a loop like this:
+
+
+
+ for (int i = 0; i < arr.Length; ++i)
+ arr [i] = 0
+
+The arr.Length load cannot be moved outside the loop, since the store inside the loop can alias it. There is a llvm.invariant.start/end intrinsic, but that seems to be only useful for marking a memory area as invariant inside a basic block, so it cannot be used to mark a load globally invariant.
+
+[http://hlvm.llvm.org/bugs/show_bug.cgi?id=5441](http://hlvm.llvm.org/bugs/show_bug.cgi?id=5441)
+
+- LLVM has no support for implicit exceptions:
+
+[http://llvm.org/bugs/show_bug.cgi?id=1269](http://llvm.org/bugs/show_bug.cgi?id=1269)
+
+- LLVM thinks that loads from a NULL address lead to undefined behaviour, while it is quite well defined on most unices (SIGSEGV signal being sent). If an optimization pass determines that the source address of a load is NULL, it changes it to undef/unreachable, changing program behaviour. The only way to work around this seems to be marking all loads as volatile, which probably doesn't help optimizations.
+- There seems to be no way to disable specific optimizations when running 'opt', i.e. do -std-compile-opts except tailcallelim.
+- The x86 JIT seems to generate normal calls as
+
+
+
+ mov reg, imm
+ call *reg
+
+This makes it hard/impossible to patch the calling address after the called method has been compiled. \ [http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-December/027999.html](http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-December/027999.html)
+
+- LLVM Bugs: [[1]](http://llvm.org/bugs/show_bug.cgi?id=6102)
+
+Future Work
+-----------
+
+### Array Bounds Check (ABC) elimination
+
+Mono already contains a ABC elimination pass, which is fairly effective at eliminating simple bounds check, i.e. the one in:
+
+for (int i = 0; i \< arr.Length; ++i)
+
+ sum += arr [i];
+
+However, it has problems with "partially redundant" check, i.e. checks which cannot be proven to be reduntant, but they are unlikely to be hit at runtime. With LLVM's extensive analysis and program transformation passes, it might be possible to eliminate these from loops, by changing them to loop-invariant checks and hoisting them out of loops, i.e. changing:
+
+ for (int i = 0; i < len; ++i)
+ sum += arr [i];
+
+to:
+
+ if (len < arr.Length) {
+
+ } else {
+
+ }
+
+LLVM has a LoopUnswitch pass which can do something like this for constant expressions, it needs to be extended to handle the ABC checks too. Unfortunately, this cannot be done currently because the arr.Length instruction is converted to a volatile load by mono's LLVM backend, since it can fault if arr is null. This means that the load is not loop invariant, so it cannot be hoisted out of the loop.
diff --git a/docs/design/mono/web/memory-management.md b/docs/design/mono/web/memory-management.md
new file mode 100644
index 000000000000..75755969163a
--- /dev/null
+++ b/docs/design/mono/web/memory-management.md
@@ -0,0 +1,48 @@
+# Memory Management
+
+Metadata memory management
+--------------------------
+
+Most metadata structures have a lifetime which is equal to the MonoImage where they are loaded from. These structures should be allocated from the memory pool of the corresponding MonoImage. The memory pool is protected by the loader lock. Examples of metadata structures in this category:
+
+- MonoClass
+- MonoMethod
+- MonoType
+
+Memory owned by these structures should be allocated from the image mempool as well. Examples include: klass-\>methods, klass-\>fields, method-\>signature etc.
+
+Generics complicates things. A generic class could have many instantinations where the generic arguments are from different assemblies. Where should we allocate memory for instantinations ? We can allocate from the mempool of the image which contains the generic type definition, but that would mean that the instantinations would remain in memory even after the assemblies containing their type arguments are unloaded, leading to a memory leak. Therefore, we do the following:
+
+- data structures representing the generic definitions are allocated from the image mempool as usual. These include:
+
+
+
+ * generic class definition (MonoGenericClass->container_class)
+ * generic method definitions
+ * type parameters (MonoGenericParam)
+
+- data structures representing inflated classes/images are allocated from the heap. They are owned by an 'image-set' which is the set of all images they depend on. When an image is unloaded, all image-sets it belongs to are freed, causing the data structures owned by the image-sets to be freed too. The structures handled this way include:
+
+
+
+ * MonoGenericClass
+ * MonoGenericInst
+ * inflated MonoMethods
+
+[Original version of this document in git.](https://github.com/mono/mono/blob/425844619cbce18eaa64205b9007f0c833e4a5c4/docs/memory-management.txt)
+
+Memory management for executable code
+-------------------------------------
+
+Executable code is managed using 'code-managers', whose implementation is in utils/mono-codeman.{h,c}. These allow the allocation of memory which is suitable for storing executable code, i.e.:
+
+- It has the required executable (x) permission.
+- The alignment of the memory blocks allocated from the code manager matches the preferred function alignment of the platform.
+
+Code managers also allow a certain percent of the memory they manage to be reserved for storing things like function thunks.
+
+The runtime contains the following code managers:
+
+- There is a global code manager declared in mini.c which is used to manage code memory whose lifetime is equal to the lifetime of the runtime. Memory for trampolines is allocated from the global code manager.
+- Every domain has a code manager which is used for allocating memory used by JITted code belonging to that domain.
+- Every 'dynamic' method, i.e. a method whose lifetime is not equal to the runtime or a domain, has its own code manager.
diff --git a/docs/design/mono/web/mini-porting.md b/docs/design/mono/web/mini-porting.md
new file mode 100644
index 000000000000..8d3977982ce5
--- /dev/null
+++ b/docs/design/mono/web/mini-porting.md
@@ -0,0 +1,373 @@
+# Porting the Engine
+
+## Introduction
+
+This documents describes the process of porting the mono JIT to a new CPU architecture. The new mono JIT has been designed to make porting easier though at the same time enable the port to take full advantage from the new architecture features and instructions. Knowledge of the mini architecture (described in the mini-doc.txt file) is a requirement for understanding this guide, as well as an earlier document about porting the mono interpreter (available on the web site).
+
+There are six main areas that a port needs to implement to have a fully-functional JIT for a given architecture:
+
+- instruction selection
+- native code emission
+- call conventions and register allocation
+- method trampolines
+- exception handling
+- minor helper methods
+
+To take advantage of some not-so-common processor features (for example conditional execution of instructions as may be found on ARM or ia64), it may be needed to develop an high-level optimization, but doing so is not a requirement for getting the JIT to work.
+
+We'll see in more details each of the steps required, note, though, that a new port may just as well start from a cut and paste of an existing port to a similar architecture (for example from x86 to amd64, or from powerpc to sparc).
+
+The architecture specific code is split from the rest of the JIT, for example the x86 specific code and data is all included in the following files in the distribution:
+
+mini-x86.h mini-x86.c inssel-x86.brg cpu-pentium.md tramp-x86.c exceptions-x86.c
+
+I suggest a similar split for other architectures as well.
+
+Note that this document is still incomplete: some sections are only sketched and some are missing, but the important info to get a port going is already described.
+
+## Architecture-specific instructions and instruction selection
+
+The JIT already provides a set of instructions that can be easily mapped to a great variety of different processor instructions. Sometimes it may be necessary or advisable to add a new instruction that represent more closely an instruction in the architecture. Note that a mini instruction can be used to represent also a short sequence of CPU low-level instructions, but note that each instruction represents the minimum amount of code the instruction scheduler will handle (i.e., the scheduler won't schedule the instructions that compose the low-level sequence as individual instructions, but just the whole sequence, as an indivisible block).
+
+New instructions are created by adding a line in the mini-ops.h file, assigning an opcode and a name. To specify the input and output for the instruction, there are two different places, depending on the context in which the instruction gets used.
+
+If an instruction is used as a low-level CPU instruction, the info is specified in a machine description file. The description file is processed by the genmdesc program to provide a data structure that can be easily used from C code to query the needed info about the instruction.
+
+As an example, let's consider the add instruction for both x86 and ppc:
+
+ x86 version:
+ add: dest:i src1:i src2:i len:2 clob:1
+ ppc version:
+ add: dest:i src1:i src2:i len:4
+
+Note that the instruction takes two input integer registers on both CPU, but on x86 the first source register is clobbered (clob:1) and the length in bytes of the instruction differs.
+
+Note that integer adds and floating point adds use different opcodes, unlike the IL language (64 bit add is done with two instructions on 32 bit architectures, using a add that sets the carry and an add with carry).
+
+A specific CPU port may assign any meaning to the clob field for an instruction since the value will be processed in an arch-specific file anyway.
+
+See the top of the existing cpu-pentium.md file for more info on other fields: the info may or may not be applicable to a different CPU, in this latter case the info can be ignored.
+
+So, one of the first things needed in a port is to write a cpu-$(arch).md machine description file and fill it with the needed info. As a start, only a few instructions can be specified, like the ones required to do simple integer operations. The default rules of the instruction selector will emit the common instructions and so we're ready to go for the next step in porting the JIT.
+
+## Native code emission
+
+Since the first step in porting mono to a new CPU is to port the interpreter, there should be already a file that allows the emission of binary native code in a buffer for the architecture. This file should be placed in the
+
+``` bash
+ mono/arch/$(arch)/
+```
+
+directory.
+
+The bulk of the code emission happens in the mini-$(arch).c file, in a function called `mono_arch_output_basic_block ()`. This function takes a basic block, walks the list of instructions in the block and emits the binary code for each. Optionally a peephole optimization pass is done on the basic block, but this can be left for later, when the port actually works.
+
+This function is very simple, there is just a big switch on the instruction opcode and in the corresponding case the functions or macros to emit the binary native code are used. Note that in this function the lengths of the instructions are used to determine if the buffer for the code needs enlarging.
+
+To complete the code emission for a method, a few other functions need implementing as well:
+
+``` c
+ mono_arch_emit_prolog ()
+ mono_arch_emit_epilog ()
+ mono_arch_patch_code ()
+```
+
+`mono_arch_emit_prolog ()` will emit the code to setup the stack frame for a method, optionally call the callbacks used in profiling and tracing, and move the arguments to their home location (in a caller-save register if the variable was allocated to one, or in a stack location if the argument was passed in a volatile register and wasn't allocated a non-volatile one). caller-save registers used by the function are saved in the prolog as well.
+
+`mono_arch_emit_epilog ()` will emit the code needed to return from the function, optionally calling the profiling or tracing callbacks. At this point the basic blocks or the code that was moved out of the normal flow for the function can be emitted as well (this is usually done to provide better info for the static branch predictor). In the epilog, caller-save registers are restored if they were used.
+
+Note that, to help exception handling and stack unwinding, when there is a transition from managed to unmanaged code, some special processing needs to be done (basically, saving all the registers and setting up the links in the Last Managed Frame structure).
+
+When the epilog has been emitted, the upper level code arranges for the buffer of memory that contains the native code to be copied in an area of executable memory and at this point, instructions that use relative addressing need to be patched to have the right offsets: this work is done by `mono_arch_patch_code ()`.
+
+## Call conventions and register allocation
+
+To account for the differences in the call conventions, a few functions need to be implemented.
+
+`mono_arch_allocate_vars ()` assigns to both arguments and local variables the offset relative to the frame register where they are stored, dead variables are simply discarded. The total amount of stack needed is calculated.
+
+`mono_arch_call_opcode ()` is the function that more closely deals with the call convention on a given system. For each argument to a function call, an instruction is created that actually puts the argument where needed, be it the stack or a specific register. This function can also re-arrange th order of evaluation when multiple arguments are involved if needed (like, on x86 arguments are pushed on the stack in reverse order). The function needs to carefully take into accounts platform specific issues, like how structures are returned as well as the differences in size and/or alignment of managed and corresponding unmanaged structures.
+
+The other chunk of code that needs to deal with the call convention and other specifics of a CPU, is the local register allocator, implemented in a function named `mono_arch_local_regalloc ()`. The local allocator deals with a basic block at a time and basically just allocates registers for temporary values during expression evaluation, spilling and unspilling as necessary.
+
+The local allocator needs to take into account clobbering information, both during simple instructions and during function calls and it needs to deal with other architecture-specific weirdnesses, like instructions that take inputs only in specific registers or output only is some.
+
+Some effort will be put later in moving most of the local register allocator to a common file so that the code can be shared more for similar, risc-like CPUs. The register allocator does a first pass on the instructions in a block, collecting liveness information and in a backward pass on the same list performs the actual register allocation, inserting the instructions needed to spill values, if necessary.
+
+The cross-platform local register allocator is now implemented and it is documented in the jit-regalloc file.
+
+When this part of code is implemented, some testing can be done with the generated code for the new architecture. Most helpful is the use of the --regression command line switch to run the regression tests (basic.cs, for example).
+
+Note that the JIT will try to initialize the runtime, but it may not be able yet to compile and execute complex code: commenting most of the code in the `mini_init()` function in mini.c is needed to let the JIT just compile the regression tests. Also, using multiple -v switches on the command line makes the JIT dump an increasing amount of information during compilation.
+
+Values loaded into registers need to be extended as needed by the ECMA specs:
+
+- integers smaller than 4 bytes are extended to int32 values
+- 32 bit floats are extended to double precision (in particular this means that currently all the floating point operations operate on doubles)
+
+## Method trampolines
+
+To get better startup performance, the JIT actually compiles a method only when needed. To achieve this, when a call to a method is compiled, we actually emit a call to a magic trampoline. The magic trampoline is a function written in assembly that invokes the compiler to compile the given method and jumps to the newly compiled code, ensuring the arguments it received are passed correctly to the actual method.
+
+Before jumping to the new code, though, the magic trampoline takes care of patching the call site so that next time the call will go directly to the method instead of the trampoline. How does this all work?
+
+`mono_arch_create_jit_trampoline ()` creates a small function that just preserves the arguments passed to it and adds an additional argument (the method to compile) before calling the generic trampoline. This small function is called the specific trampoline, because it is method-specific (the method to compile is hard-code in the instruction stream).
+
+The generic trampoline saves all the arguments that could get clobbered and calls a C function that will do two things:
+
+- actually call the JIT to compile the method
+- identify the calling code so that it can be patched to call directly the actual method
+
+If the 'this' argument to a method is a boxed valuetype that is passed to a method that expects just a pointer to the data, an additional unboxing trampoline will need to be inserted as well.
+
+## Exception handling
+
+Exception handling is likely the most difficult part of the port, as it needs to deal with unwinding (both managed and unmanaged code) and calling catch and filter blocks. It also needs to deal with signals, because mono takes advantage of the MMU in the CPU and of the operation system to handle dereferences of the NULL pointer. Some of the function needed to implement the mechanisms are:
+
+`mono_arch_get_throw_exception ()` returns a function that takes an exception object and invokes an arch-specific function that will enter the exception processing. To do so, all the relevant registers need to be saved and passed on.
+
+`mono_arch_handle_exception ()` this function takes the exception thrown and a context that describes the state of the CPU at the time the exception was thrown. The function needs to implement the exception handling mechanism, so it makes a search for an handler for the exception and if none is found, it follows the unhandled exception path (that can print a trace and exit or just abort the current thread). The difficulty here is to unwind the stack correctly, by restoring the register state at each call site in the call chain, calling finally, filters and handler blocks while doing so.
+
+As part of exception handling a couple of internal calls need to be implemented as well.
+
+`ves_icall_get_frame_info ()` returns info about a specific frame.
+
+`mono_jit_walk_stack ()` walks the stack and calls a callback with info for each frame found.
+
+`ves_icall_get_trace ()` return an array of StackFrame objects.
+
+### Code generation for filter/finally handlers
+
+Filter and finally handlers are called from 2 different locations:
+
+- from within the method containing the exception clauses
+- from the stack unwinding code
+
+To make this possible we implement them like subroutines, ending with a "return" statement. The subroutine does not save the base pointer, because we need access to the local variables of the enclosing method. Its is possible that instructions inside those handlers modify the stack pointer, thus we save the stack pointer at the start of the handler, and restore it at the end. We have to use a "call" instruction to execute such finally handlers.
+
+The MIR code for filter and finally handlers looks like:
+
+ OP_START_HANDLER
+ ...
+ OP_END_FINALLY | OP_ENDFILTER(reg)
+
+OP_START_HANDLER: should save the stack pointer somewhere OP_END_FINALLY: restores the stack pointers and returns. OP_ENDFILTER (reg): restores the stack pointers and returns the value in "reg".
+
+### Calling finally/filter handlers
+
+There is a special opcode to call those handler, its called OP_CALL_HANDLER. It simple emits a call instruction.
+
+Its a bit more complex to call handler from outside (in the stack unwinding code), because we have to restore the whole context of the method first. After that we simply emit a call instruction to invoke the handler. Its usually possible to use the same code to call filter and finally handlers (see arch_get_call_filter).
+
+### Calling catch handlers
+
+Catch handlers are always called from the stack unwinding code. Unlike finally clauses or filters, catch handler never return. Instead we simply restore the whole context, and restart execution at the catch handler.
+
+### Passing Exception objects to catch handlers and filters
+
+We use a local variable to store exception objects. The stack unwinding code must store the exception object into this variable before calling catch handler or filter.
+
+## Minor helper methods
+
+A few minor helper methods are referenced from the arch-independent code. Some of them are:
+
+`mono_arch_cpu_optimizations ()` This function returns a mask of optimizations that should be enabled for the current CPU and a mask of optimizations that should be excluded, instead.
+
+`mono_arch_regname ()` Returns the name for a numeric register.
+
+`mono_arch_get_allocatable_int_vars ()` Returns a list of variables that can be allocated to the integer registers in the current architecture.
+
+`mono_arch_get_global_int_regs ()` Returns a list of caller-save registers that can be used to allocate variables in the current method.
+
+`mono_arch_instrument_mem_needs ()`
+
+`mono_arch_instrument_prolog ()`
+
+`mono_arch_instrument_epilog ()` Functions needed to implement the profiling interface.
+
+## Testing the port
+
+The JIT has a set of regression tests in \*.cs files inside the mini directory.
+
+The usual method of testing a port is by compiling these tests on another machine with a working runtime by typing 'make rcheck', then copying TestDriver.dll and \*.exe to the mini directory. The tests can be run by typing:
+
+``` bash
+ ./mono --regression
+```
+
+The suggested order for working through these tests is the following:
+
+- basic.exe
+- basic-long.exe
+- basic-float.exe
+- basic-calls.exe
+- objects.exe
+- arrays.exe
+- exceptions.exe
+- iltests.exe
+- generics.exe
+
+## Writing regression tests
+
+Regression tests for the JIT should be written for any bug found in the JIT in one of the \*.cs files in the mini directory. Eventually all the operations of the JIT should be tested (including the ones that get selected only when some specific optimization is enabled).
+
+## Platform specific optimizations
+
+An example of a platform-specific optimization is the peephole optimization: we look at a small window of code at a time and we replace one or more instructions with others that perform better for the given architecture or CPU.
+
+## Function descriptors
+
+Some ABIs, like those for IA64 and PPC64, don't use direct function pointers, but so called function descriptors. A function descriptor is a short data structure which contains at least a pointer to the code of the function and a pointer to a GOT/TOC, which needs to be loaded into a specific register prior to jumping to the function. Global variables and large constants are accessed through that register.
+
+Mono does not need function descriptors for the JITted code, but we need to handle them when calling unmanaged code and we need to create them when passing managed code to unmanaged code.
+
+`mono_create_ftnptr()` creates a function descriptor for a piece of generated code within a specific domain.
+
+`mono_get_addr_from_ftnptr()` returns the pointer to the native code in a function descriptor. Never use this function to generate a jump to a function without loading the GOT/TOC register unless the function descriptor was created by `mono_create_ftnptr()`.
+
+See the sources for IA64 and PPC64 on when to create and when to dereference function descriptors. On PPC64 function descriptors for various generated helper functions (in exceptions-ppc.c and tramp-ppc.c) are generated in front of the code they refer to (see `ppc_create_pre_code_ftnptr()`). On IA64 they are created separately.
+
+## Emulated opcodes
+
+Mini has code for emulating quite a few opcodes, most notably operations on longs, int/float conversions and atomic operations. If an architecture wishes such an opcode to be emulated, mini produces icalls instead of those opcodes. This should only be considered when the operation cannot be implemented efficiently and thus the overhead occured by the icall is not relatively large. Emulation of operations is controlled by #defines in the arch header, but the naming is not consistent. They usually start with `MONO_ARCH_EMULATE_`, `MONO_ARCH_NO_EMULATE_` and `MONO_ARCH_HAVE_`.
+
+## Prolog/Epilog
+
+The method prolog is emitted by the mono_arch_emit_prolog () function. It usually consists of the following parts:
+
+- Allocate frame: set fp to sp, decrement sp.
+- Save callee saved registers to the frame
+- Initialize the LMF structure
+- Link the LMF structure: This implements the following pseudo code:
+
+
+
+ lmf->lmf_addr = mono_get_lmf_addr ()
+ lmf->previous_lmf = *(lmf->lmf_addr)
+ *(lmf->lmf_addr)->lmf
+
+- Compute bb->max_offset for each basic block: This enables mono_jit_output_basic_block () to emit short branches where possible.
+- Store the runtime generic context, see the Generic Sharing section.
+- Store the signature cookie used by vararg methods.
+- Transfer arguments to the location they are allocated to, i.e. load arguments received on the stack to registers if needed, and store arguments received in registers to the stack/callee saved registers if needed.
+- Initialize the various variables used by the soft debugger code.
+- Implement tracing support.
+
+The epilog is emitted by the mono_arch_emit_epilog () function. It usually consists of the following parts:
+
+- Restore the LMF by doing:
+
+
+
+ *(lmf->lmf_addr) = lmf->previous_lmf.
+
+- Load returned valuetypes into registers if needed.
+- Implement tracing support.
+- Restore callee saved registers.
+- Pop frame.
+- Return to the caller.
+
+Care must be taken during these steps to avoid clobbering the registers holding the return value of the method.
+
+Callee saved registers are either saved to dedicated stack slots, or they are saved into the LMF. The stack slots where various things are saved are allocated by mono_arch_allocate_vars ().
+
+## Delegate Invocation
+
+A delegate is invoked like this by JITted code:
+
+delegate->invoke_impl (delegate, arg1, arg2, arg3, ...)
+
+Here, 'invoke_impl' originally points to a trampoline which ends up calling the 'mono_delegate_trampoline' C function. This function tries to find an architecture specific optimized implementation by calling 'mono_arch_get_delegate_invoke_impl'.
+
+mono_arch_get_delegate_invoke_impl () should return a small trampoline for invoking the delegate which matches the following pseudo code:
+
+-for instance delegates:
+
+delegate->method_ptr (delegate->target, arg1, arg2, arg3, ...)
+
+- for static delegates:
+
+delegate->method_ptr (arg1, arg2, arg3, ...)
+
+## Varargs
+
+The vararg calling convention is implemented as follows:
+
+### Caller side
+
+- The caller passes in a 'signature cookie', which is a hidden argument containing a MonoSignature\*.
+
+
+
+ This argument is passed just before the implicit arguments, i.e. if the callee signature is this:
+ foo (string format, ...)
+
+and the callee signature is this:
+
+ foo ("%d %d", 1, 2)
+
+then the real callee signature would look like:
+
+ foo ("%d %d", , 1, 2)
+
+To simplify things, both the sig cookie and the implicit arguments are always passed on the stack and not in registers. mono_arch_emit_call () is responsible for emitting this argument.
+
+### Callee side
+
+- mono_arch_allocate_vars () is responsible for allocating a local variable slot where the sig cookie will be saved. cfg->sig_cookie should contain the stack offset of the local variable slot.
+- mono_arch_emit_prolog () is responsible for saving the sig cookie argument into the local variable.
+- The implementation of OP_ARGLIST should load the sig cookie from the local variable, and save it into its dreg, which will point to a local variable of type RuntimeArgumentHandle.
+- The fetching of vararg arguments is implemented by icalls in icalls.c.
+
+tests/vararg.exe contains test cases to exercise this functionality.
+
+## Unwind info
+
+On most platforms, the JIT uses DWARF unwind info to unwind the stack during exception handling. The API and some documentation is in the mini-unwind.h file. The mono_arch_emit_prolog () function is required to emit this information using the macros in mini-unwind.h, and the mono_arch_find_jit_info () function needs to pass it to mono_unwind_frame (). In addition to this, the various trampolines might also have unwind info, which makes stack walks possible when using the gdb integration (XDEBUG).
+
+The task of a stack unwinder is to construct the machine state at the caller of the current stack frame, i.e: - find the return address of the caller - find the values of the various callee saved registers in the caller at the point of the call
+
+The DWARF unwinder is based on the concept of a CFA, or Canonical Frame Address. This is an address of the stack frame which does not change during the execution of the method. By convention, the CFA is equal to the value of the stack pointer prior to the instruction which transferred execution to the current method. So for example, on x86, the value of the CFA on enter to the method is esp+4 because of the pushing of the return address. There are two kinds of unwind directives:
+
+- those that specify how to compute the CFA at any point in the method using a \+\
+- those that specify where a given register is saved in relation to the CFA.
+
+For a typical x86 method prolog, the unwind info might look like this:
+
+``` bash
+-
+-
+push ebp
+-
+mov ebp, esp
+-
+```
+
+## Generic Sharing
+
+Generic code sharing is optional. See the document on [generic-sharing](/docs/advanced/runtime/docs/generic-sharing/) for information on how to support it on an architecture.
+
+### MONO_ARCH_RGCTX_REG
+
+The MONO_ARCH_RGCTX_REG define should be set to a hardware register which will be used to pass the 'mrgctx' hidden argument to generic shared methods. It should be a caller saved register which is not used in local register allocation. Also, any code which gets executed between the caller and the callee (i.e. trampolines) needs to avoid clobbering this registers. The easiest solution is to set it to the be the same as MONO_ARCH_IMT_REG, since IMT/generic sharing are never used together during a call. The method prolog must save this register to cfg->rgctx_var.
+
+### Static RGCTX trampolines
+
+These trampolines are created by mono_arch_get_static_rgctx_trampoline (). They are used to call generic shared methods indirectly from code which cannot pass an MRGCTX. They should implement the following pseudo code:
+
+ = mrgctx
+ jump
+
+### Generic Class Init Trampoline
+
+This one of a kind trampoline is created by mono_arch_create_generic_class_init_trampoline (). They are used to run the .cctor of the vtable passed in as an argument in MONO_ARCH_VTABLE_REG. They should implement the following pseudo code:
+
+ vtable =
+ if (!vtable->initialized)
+
+
+The generic trampoline code needs to be modified to pass the argument received in MONO_ARCH_VTABLE_REG to the C trampoline function, which is mono_generic_class_init_trampoline ().
+
+### RGCTX Lazy Fetch Trampoline
+
+These trampolines are created by mono_arch_create_rgctx_lazy_fetch_trampoline (). They are used for fetching values out of an MonoRuntimeGenericContext, lazily initializing them as needed.
diff --git a/docs/design/mono/web/mono-error.md b/docs/design/mono/web/mono-error.md
new file mode 100644
index 000000000000..dd4c9f057546
--- /dev/null
+++ b/docs/design/mono/web/mono-error.md
@@ -0,0 +1,144 @@
+# Error handling and MonoError
+
+## MonoError
+
+MonoError is the latest attempt at cleaning up and sanitizing error handling in the runtime. This document highlights some of the design goals and decisions, the implementation and the migration strategy.
+
+### Design goals
+
+- Replace the majority of the adhoc error handling subsystems present today in the runtime. Each one is broken in a subtle way, has slightly different semantics and error conversion between them is spot, at best.
+
+- Map well to the final destination of all runtime errors: managed exceptions. This includes being compatible with .net when it comes to the kind of exception produced by a given error condition.
+
+- Be explicit, lack any magic. The loader-error setup does control flow happens in the background through a TLS variable, which made it very brittle and error prone.
+
+- Explicit and multiple error scopes. Make it possible to have multiple error scopes and make them explicit. We need to support nested scopes during type loading, even if reporting is flat.
+
+- Be as simple as possible. Error handling is the hardest part of the runtime to test so it must be simple. Which means complex error reporting, such as chaining, is out of question.
+
+## Current implementation
+
+The current implementation exists in mono-error.h and mono-error-internals.h. The split is so API users can consume errors, but they are not supported to be able to produce them - such use case has yet to arise.
+
+#### Writing a function that produces errors
+
+``` c
+/**
+ *
+ * @returns NULL on error
+ */
+void*
+my_function (int a, MonoError *error)
+{
+ if (a <= 0) {//
+ mono_error_set_argument (error, "a", "argument a must be bigger than zero, it was %d", a);
+ return NULL;
+ }
+ return malloc (a);
+}
+```
+
+Important points from the above:
+
+- Add a "MonoError \*error" argument as the last to your function
+- Call one of the mono_error_set functions based on what managed exception this should produce and the available information
+- Document that a NULL returns means an error
+
+## Writing a function that consumes errors
+
+``` c
+void
+other_function (void)
+{
+ ERROR_DECL (error);
+ void *res;
+
+ res = my_function (10, error);
+ //handling the error:
+ //1st option: set the pending exception. Only safe to do in icalls
+ if (mono_error_set_pending_exception (error)) //returns TRUE if an exception was set
+ return;
+
+ //2nd option: legacy code that can't handle failures:
+ mono_error_assert_ok (error);
+
+ //3rd option (deprecated): raise an exception and write a FIXME note
+ // (implicit cleanup, no-op if there was no error)
+ mono_error_raise_exception (error); /* FIXME don't raise here */
+
+ //4th option: ignore
+ mono_error_cleanup (error);
+}
+```
+
+Important points from the above:
+
+- Use `ERROR_DECL (error)` to declare and initialize a `MonoError *error` variable. (Under the hood, it declares a local `MonoError error_value` using `ERROR_DECL_VALUE (error_value)`. You may use `ERROR_DECL_VALUE (e)` to declare a variable local variable yourself. It's pretty unusual to need to do that, however.)
+- Pass it to the required function and always do something with the result
+- Given we're still transitioning, not all code can handle in the same ways
+
+## Handling the transition
+
+The transition work is not complete and we're doing it piece-by-piece to ensure we don't introduce massive regressions in the runtime. The idea is to move the least amount of code a time to use the new error machinery.
+
+Here are the rules for code conversion:
+
+- Mono API functions that need to call functions which take a MonoError should assert on failure or cleanup the error as there's no adequate alternative at this point. They **must not** use `mono_error_raise_exception` or `mono_error_set_pending_exception`
+
+- When possible, change the function signature. If not, add a \_checked variant and add the `MONO_RT_EXTERNAL_ONLY` to the non-checked version if it's in the Mono API. That symbol will prevent the rest of the Mono runtime from calling the non-checked version.
+
+## Advanced technique: using a local error to raise a different exception
+
+Suppose you want to call a function `foo_checked()` but you want to raise a different exception if it fails. In this case, it makes sense to create a local error variable to handle the call to `foo_checked`:
+
+``` c
+int
+my_function (MonoObject *arg, MonoError *error)
+{
+ ERROR_DECL (local_error);
+ int result = foo_checked (arg, local_error);
+ if (!is_ok (local_error)) {
+ mono_error_set_execution_engine (error, "Could not successfully call foo_checked, due to: %s", mono_error_get_message (local_error));
+ mono_error_cleanup (local_error);
+ }
+ return result;
+```
+
+- Pass `local_error` to `foo_checked`
+- Check the result and if it wasn't okay, set a different error code on `error` It is common to use `mono_error_get_message` to include the message from the local failure as part of the new exception
+- Cleanup `local_error` to release its resources
+
+## Advanced technique: MonoErrorBoxed and mono_class_set_failure
+
+Normally we store a `MonoError` on the stack. The usual scenario is that managed code calls into the runtime, we perform some operations, and then we either return a result or convert a `MonoError` into a pending exception. So a stack lifetime for a `MonoError` makes sense.
+
+There is one scenario where we need a heap-allocated `MonoError` whose lifetime is tied to a `MonoImage`: the initialization of a managed class. `MonoErrorBoxed` is a thin wrapper around a `MonoError` that identifies a `MonoError` that is allocated in the mempool of a `MonoImage`. It is created using `mono_error_box()` and converted back to an ordinary `MonoError` using `mono_error_unbox()`.
+
+``` c
+static int
+some_class_init_helper (MonoClass *k)
+{
+ if (mono_class_has_failure (k))
+ return -1; /* Already a failure, don't bother trying to init it */
+ ERROR_DECL (local_error);
+ int result = foo_checked (k, local_error);
+ if (!is_ok (error)) {
+ mono_class_set_failure (k, mono_error_box (local_error, k->image));
+ mono_error_cleanup (local_error);
+ }
+ return result;
+}
+```
+
+- Check whether the class is already marked as a failure
+- Pass a `local_error` to `foo_checked`
+- Check the result and if it wasn't okay, allocate a boxed `MonoError` in the mempool of the class's image
+- Mark the class that failed with the boxed error
+- Cleanup the `local_error` to release its resources
+
+### Design issues
+
+- Memory management of the error setting functions is not consistent or clear
+- Use a static initializer in the declaration site instead of mono_error_init?
+- Force an error to always be set or only when there's an exception situation? I.E. mono_class_from_name failing to find the class X finding the class but it failed to load.
+- g_assert (mono_errork_ok (&error)) could be replaced by a macro that uses g_error so we can see the error contents on crashes.
diff --git a/docs/design/mono/web/other.md b/docs/design/mono/web/other.md
new file mode 100644
index 000000000000..f3bfe69601b8
--- /dev/null
+++ b/docs/design/mono/web/other.md
@@ -0,0 +1,105 @@
+# Other notes
+
+## Faster runtime builds
+
+To speed up runtime builds, use one or more of the following:
+
+- Turn off optimization by passing CFLAGS=-O0 to configure.
+- Turn off generation of libmono by passing --disable-libraries to configure.
+- Turn off boeh support by passing --disable-boehm to configure.
+- Build in parallel, i.e. using make -j4.
+- Use ccache by passing CC="ccache gcc" CXX="ccache g++" to configure.
+
+## Runtime debugging methods
+
+### Debugging crashes which don't happen inside gdb, or only happen when a test program is ran in a loop
+
+Set the MONO_DEBUG env variable to 'suspend-on-sigsegv'. This causes the runtime native SIGSEGV handler to spin in a loop, so gdb can be attached to the running process.
+
+### Setting native breakpoints in managed methods
+
+Use the --break \ command line argument. The JIT will generate a native breakpoint (INT on x86) into the prolog of the given method. Use --break-at-bb \ \ to set a breakpoint at the start of a given basic block.
+
+### Displaying JIT debug output
+
+Use the -v -v -v -v command line argument. Set the MONO_VERBOSE_METHOD env variable to display output for only one method.
+
+### Dumping JIT IR to IGV
+
+Set `MONO_JIT_DUMP_METHOD` to specify a method to dump over network to a running instance of the [IdealGraphVisualizer (IGV)](http://ssw.jku.at/General/Staff/TW/igv.html). An IGV build that is compatible with the implementation in Mono is available for [Mac/Linux/Windows](https://github.com/lewurm/GraalJVMCI8/releases/tag/v0.1) and requires at least JRE 1.7 to run.
+
+On Mac:
+
+``` bash
+$ # unpack zip file
+$ open idealgraphvisualizer
+.
+```
+
+For Linux there's `bin/idealgraphvisualizer` and for Windows there's `bin/idealgraphvisualizer.exe`. After starting IGV, it will listen on port 4445 and is ready to receive graphs.
+
+Here an example for dumping the IR of a method:
+
+``` bash
+$ cat fib.cs
+using System;
+
+public class Fib {
+
+ public static int fib (int n) {
+ if (n < 2)
+ return 1;
+ return fib(n-2)+fib(n-1);
+ }
+ public static int Main (string[] args) {
+ int repeat = 1;
+
+ if (args.Length == 1)
+ repeat = Convert.ToInt32 (args [0]);
+
+ // Console.WriteLine ("Repeat = " + repeat);
+
+ if (repeat > 32) {
+ Console.WriteLine ("{0}", fib (repeat));
+ return 0;
+ }
+
+ for (int i = 0; i < repeat; i++)
+ if (fib (32) != 3524578)
+ return 1;
+
+ return 0;
+ }
+}
+$ csc fib.cs
+$ MONO_JIT_DUMP_METHOD=Fib::fib mono fib.exe
+cfg_dump: create context for "Fib::fib"
+```
+
+now switch to IGV, you should see something like that: [](images/igv-screenshot.png)
+
+you can explore the different compiler passes in the navigation bar on the left side. IGV also has a graph diff feature:
+
+[](/images/igv-diff.png)
+
+### Displaying runtime debug output
+
+Set the MONO_LOG_LEVEL env variable to 'debug'. The log output is useful for diagnosing assembly loading/AOT/pinvoke problems.
+
+### mono_debug_count ()
+
+This is useful for debugging problems where a piece of code is executed many times, and we need to find out which run causes the runtime to misbehave, i.e. which method is miscompiled by the JIT etc. It works by changing
+
+``` bash
+do_something ()
+```
+
+To:
+
+``` bash
+if (mono_debug_count ()) {
+
+}
+```
+
+mono_debug_count () is controlled by the COUNT env variable, the first COUNT times it is called, it will return TRUE, after that, it will return FALSE. This allows us to find out exactly which execution of \ causes the problem by running the application while varying the value of COUNT using a binary search.
diff --git a/docs/design/mono/web/register-allocation.md b/docs/design/mono/web/register-allocation.md
new file mode 100644
index 000000000000..e6247d8eb958
--- /dev/null
+++ b/docs/design/mono/web/register-allocation.md
@@ -0,0 +1,153 @@
+# Register allocation in the Mono JIT
+
+### Global Register Allocation
+
+\
+
+### Local Register Allocation
+
+This section describes the cross-platform local register allocator which is in the file mini-codegen.c.
+
+The input to the allocator is a basic block which contains linear IL, ie. instructions of the form:
+
+ DEST <- SRC1 OP SRC2
+
+where DEST, SRC1, and SRC2 are virtual registers (vregs). The job of the allocator is to assign hard or physical registers (hregs) to each virtual registers so the vreg references in the instructions can be replaced with their assigned hreg, allowing machine code to be generated later.
+
+The allocator needs information about the number and types of arguments of instructions. It takes this information from the machine description files. It also needs arch specific information, like the number and type of the hard registers. It gets this information from arch-specific macros.
+
+Currently, the vregs and hregs are partitioned into two classes: integer and floating point.
+
+The allocator consists of two phases: In the first phase, a forward pass is made over the instructions, collecting liveness information for vregs. In the second phase, a backward pass is made over the instructions, assigning registers. This backward mode of operation makes the allocator somewhat difficult to understand, but leads to better code in most cases.
+
+#### Allocator state
+
+The state of the allocator is stored in two arrays: iassign and isymbolic. iassign maps vregs to hregs, while isymbolic is the opposite. For a vreg, iassign [vreg] can contain the following values:
+
+ -1 vreg has no assigned hreg
+
+ hreg index (>= 0) vreg is assigned to the given hreg. This means later instructions (which we have already processed due to the backward direction) expect the value of vreg to be found in hreg.
+
+ spill slot index (< -1) vreg is spilled to the given spill slot. This means later instructions expect the value of vreg to be found on the stack in the given spill slot. When this vreg is used as a dreg of an instruction, a spill store needs to be generated after the instruction saving its value to the given spill slot.
+
+Also, the allocator keeps track of which hregs are free and which are used. This information is stored in a bitmask called ifree_mask.
+
+There is a similar set of data structures for floating point registers.
+
+#### Spilling
+
+When an allocator needs a free hreg, but all of them are assigned, it needs to free up one of them. It does this by spilling the contents of the vreg which is currently assigned to the selected hreg. Since later instructions expect the vreg to be found in the selected hreg, the allocator emits a spill-load instruction to load the value from the spill slot into the hreg after the currently processed instruction. When the vreg which is spilled is a destination in an instruction, the allocator will emit a spill-store to store the value into the spill slot.
+
+#### Fixed registers
+
+Some architectures, notably x86/amd64 require that the arguments/results of some instructions be assigned to specific hregs. An example is the shift opcodes on x86, where the second argument must be in ECX. The allocator has support for this. It tries to allocate the vreg to the required hreg. If thats not possible, then it will emit compensation code which moves values to the correct registers before/after the instruction.
+
+Fixed registers are mainly used on x86, but they are useful on more regular architectures on well, for example to model that after a call instruction, the return of the call is in a specific register.
+
+A special case of fixed registers is two address architectures, like the x86, where the instructions place their results into their first argument. This is modelled in the allocator by allocating SRC1 and DEST to the same hreg.
+
+#### Global registers
+
+Some variables might already be allocated to hardware registers during the global allocation phase. In this case, SRC1, SRC2 and DEST might already be a hardware register. The allocator needs to do nothing in this case, except when the architecture uses fixed registers, in which case it needs to emit compensation code.
+
+#### Register pairs
+
+64 bit arithmetic on 32 bit machines requires instructions whose arguments are not registers, but register pairs. The allocator has support for this, both for freely allocatable register pairs, and for register pairs which are constrained to specific hregs (EDX:EAX on x86).
+
+#### Floating point stack
+
+The x86 architecture uses a floating point register stack instead of a set of fp registers. The allocator supports this by a post-processing pass which keeps track of the height of the fp stack, and spills/loads values from the stack as neccesary.
+
+#### Calls
+
+Calls need special handling for two reasons: first, they will clobber all caller-save registers, meaning their contents will need to be spilled. Also, some architectures pass arguments in registers. The registers used for passing arguments are usually the same as the ones used for local allocation, so the allocator needs to handle them specially. This is done as follows: the MonoInst for the call instruction contains a map mapping vregs which contain the argument values to hregs where the argument needs to be placed,like this (on amd64):
+
+ R33 -> RDI
+ R34 -> RSI
+ ...
+
+When the allocator processes the call instruction, it allocates the vregs in the map to their associated hregs. So the call instruction is processed as if having a variable number of arguments which fixed register assignments.
+
+An example:
+
+ R33 <- 1
+ R34 <- 2
+ call
+
+When the call instruction is processed, R33 is assigned to RDI, and R34 is assigned to RSI. Later, when the two assignment instructions are processed, R33 and R34 are already assigned to a hreg, so they are replaced with the associated hreg leading to the following final code:
+
+ RDI <- 1
+ RSI <- 1
+ call
+
+#### Machine description files
+
+A typical entry in the machine description files looks like this:
+
+shl: dest:i src1:i src2:s clob:1 len:2
+
+The allocator is only interested in the dest,src1,src2 and clob fields. It understands the following values for the dest, src1, src2 fields:
+
+- i - integer register
+- f - fp register
+- b - base register (same as i, but the instruction does not modify the reg)
+- m - fp register, even if an fp stack is used (no fp stack tracking)
+
+It understands the following values for the clob field:
+
+- 1 - sreg1 needs to be the same as dreg
+- c - instruction clobbers the caller-save registers
+
+Beside these values, an architecture can define additional values (like the 's' in the example). The allocator depends on a set of arch-specific macros to convert these values to information it needs during allocation.
+
+#### Arch specific macros
+
+These macros usually receive a value from the machine description file (like the 's' in the example). The examples below are for x86.
+
+ /*
+ * A bitmask selecting the caller-save registers (these are used for local
+ * allocation).
+ */
+ #define MONO_ARCH_CALLEE_REGS X86_CALLEE_REGS
+
+ /*
+ * A bitmask selecting the callee-saved registers (these are usually used for
+ * global allocation).
+ */
+ #define MONO_ARCH_CALLEE_SAVED_REGS X86_CALLER_REGS
+
+ /* Same for the floating point registers */
+ #define MONO_ARCH_CALLEE_FREGS 0
+ #define MONO_ARCH_CALLEE_SAVED_FREGS 0
+
+ /* Whenever the target uses a floating point stack */
+ #define MONO_ARCH_USE_FPSTACK TRUE
+
+ /* The size of the floating point stack */
+ #define MONO_ARCH_FPSTACK_SIZE 6
+
+ /*
+ * Given a descriptor value from the machine description file, return the fixed
+ * hard reg corresponding to that value.
+ */
+ #define MONO_ARCH_INST_FIXED_REG(desc) ((desc == 's') ? X86_ECX : ((desc == 'a') ? X86_EAX : ((desc == 'd') ? X86_EDX : ((desc == 'y') ? X86_EAX : ((desc == 'l') ? X86_EAX : -1)))))
+
+ /*
+ * A bitmask selecting the hregs which can be used for allocating sreg2 for
+ * a given instruction.
+ */
+ #define MONO_ARCH_INST_SREG2_MASK(ins) (((ins [MONO_INST_CLOB] == 'a') || (ins [MONO_INST_CLOB] == 'd')) ? (1 << X86_EDX) : 0)
+
+ /*
+ * Given a descriptor value, return whenever it denotes a register pair.
+ */
+ #define MONO_ARCH_INST_IS_REGPAIR(desc) (desc == 'l' || desc == 'L')
+
+ /*
+ * Given a descriptor value, and the first register of a regpair, return a
+ * bitmask selecting the hregs which can be used for allocating the second
+ * register of the regpair.
+ */
+ #define MONO_ARCH_INST_REGPAIR_REG2(desc,hreg1) (desc == 'l' ? X86_EDX : -1)
+
+[Original version of this document in git.](https://github.com/mono/mono/blob/4b2982c3096e3b17156bf00a062777ed364e3674/docs/jit-regalloc)
diff --git a/docs/design/mono/web/soft-debugger-wire-format.md b/docs/design/mono/web/soft-debugger-wire-format.md
new file mode 100644
index 000000000000..49facbc283df
--- /dev/null
+++ b/docs/design/mono/web/soft-debugger-wire-format.md
@@ -0,0 +1,469 @@
+# Soft Debugger Wire Format
+
+## Introduction
+
+The [Mono Soft Debugger](/docs/advanced/runtime/docs/soft-debugger/) (SDB) is a debugger implemented by the Mono runtime. The Mono runtime exposes an interface that debugger clients can use to debug a Mono application. Mono provides a convenience library in the form of the Mono.Debugger.Soft.dll that can be used to communicate with a running Mono process.
+
+The Mono.Debugger.Soft.dll library uses a protocol over sockets to debug applications. The wire protocol is inspired by the [JDWP (Java Debug Wire Protocol)](http://download.oracle.com/javase/1,5.0/docs/guide/jpda/jdwp-spec.html). Familiarity with that specification is a good read.
+
+This document describes the wire protocol used between debugging clients and the Mono runtime.
+
+Where possible, the corresponding protocol detail is linked to a function name and file location in Mono source code. These informations are based on Mono master version at revision *f42ba4a168e7cb9b9486b8a96c53752e4467be8a*.
+
+## Protocol details
+
+### Transport
+
+Mono SDB protocol, just like its Java counterpart, was designed with no specific transport in mind. However, presently the public Mono SDB only has a TCP/IP transport available (under the transport name of `dt_socket`). Other transports can be plugged by modifying this interface.
+
+#### Bootstraping a connection
+
+To boostrap a connection, the client send handshake to the server (see `debugger-agent.c:1034`) in the form of the 13 ASCII characters string "DWP-Handshake" and wait for the server reply which consist of the exact same ASCII character sequence.
+
+### Packets
+
+Just like JDWP, Mono SDB protocol is packet-based with two types of packet: command and reply. All fields in a packet is sent in big-endian format which is transparently handled in Mono source code with corresponding helper encode/decode functions.
+
+Command packet are used by either side (client or server) to request information, act on the execution of the debugged program or to inform of some event. Replies is only sent in response to a command with information on the success/failure of the operation and any extra data depending on the command that triggered it.
+
+Both type of packet contains a header. The header is always 11 bytes long. Their descriptions are given afterwards:
+
+
+
+
+ Command packet header |
+
+
+ byte 1 |
+ byte 2 |
+ byte 3 |
+ byte 4 |
+ byte 5 |
+ byte 6 |
+ byte 7 |
+ byte 8 |
+ byte 9 |
+ byte 10 |
+ byte 11 |
+
+
+
+
+ length |
+ id |
+ flags |
+ command set |
+ command |
+
+
+
+
+In Mono SDB source code, the command header is decoded in the server thread `debugger_thread` function at `debugger-agent.c:7583`.
+
+
+
+
+ Reply packet header |
+
+
+ byte 1 |
+ byte 2 |
+ byte 3 |
+ byte 4 |
+ byte 5 |
+ byte 6 |
+ byte 7 |
+ byte 8 |
+ byte 9 |
+ byte 10 |
+ byte 11 |
+
+
+
+
+ length |
+ id |
+ flags |
+ error code |
+
+
+
+In Mono SDB source code, a reply packet is constructed and sent by the `send_reply_packet` function in `debugger-agent:1514`.
+
+#### Packet field details
+
+##### Common fields
+
+length : The total length in byte of the packet including header i.e. this value will be 11 if the packet only consists of header with no other data
+
+id : Uniquely identify sent packet command/reply pair so that they can be asynchronously matched. This is in practise a simple monotonic integer counter. Note that client and server may use the same id value when sending their packets as the uniqueness property is only with respect to a specific source.
+
+flags : At the moment this value is only used with a reply packet in which case its value is set to `0x80`. A command packet should have this value set to 0.
+
+##### Command specific fields
+
+command set : This value allows grouping commands into similar blocks for quicker processing. The different command sets with their values are given below:
+
+| Command set | Value |
+|:-----------------|:------|
+| Virtual Machine | 1 |
+| Object reference | 9 |
+| String reference | 10 |
+| Threads | 11 |
+| Array reference | 13 |
+| Event request | 15 |
+| Stack frame | 16 |
+| AppDomain | 20 |
+| Assembly | 21 |
+| Method | 22 |
+| Type | 23 |
+| Module | 24 |
+| Events | 64 |
+
+command : Tell what command this packet corresponds to. This value is relative to the previously defined command set so the values are reused across different command sets. Definition of each command is given in a later chapter.
+
+##### Reply specific fields
+
+error code : Define which error occured or if the command was successful. Error code definition is given below:
+
+| Error name | Value | Mono specific notes |
+|:--------------------------|:------|:---------------------------------------------------------------------------|
+| Success | 0 | |
+| Invalid object | 20 | |
+| Invalid field ID | 25 | |
+| Invalid frame ID | 30 | |
+| Not Implemented | 100 | |
+| Not Suspended | 101 | |
+| Invalid argument | 102 | |
+| Unloaded | 103 | AppDomain has been unloaded |
+| No Invocation | 104 | Returned when trying to abort a thread which isn't in a runtime invocation |
+| Absent information | 105 | Returned when a requested method debug information isn't available |
+| No seq point at IL Offset | 106 | Returned when a breakpoint couldn't be set |
+
+#### Data type marshalling
+
+| Name | Size | Description |
+|:--------|:-----------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| byte | 1 byte | A byte value |
+| short | 2 byte | A UInt16 value |
+| int | 4 bytes | A UInt32 value |
+| long | 8 bytes | A UInt64 value |
+| id | 4 bytes | The same size is used for all IDs (ObjectID, PointerID, TypeId, MethodID, AssemblyID, ModuleID, FieldID, PropertyID, DomainID) |
+| string | At least 4 bytes | A string consists of a leading int value giving the string size followed by *size* bytes of character data. Thus an empty string is simply a 4 bytes integer value of 0 |
+| variant | At least 1 byte | A variant type is a special value which consists of a leading byte giving away the MonoType information of the variant followed directly by its raw value. |
+| boolean | 4 bytes (an int) | Tough not strictly a type, a boolean is represented by an int value whose value is 1 for true and 0 for false. |
+
+Most of the encoding function for these types are defined as `buffer_add_*` functions starting from `debugger-agent.c:1429`. Their counterpart are of the form `decode_*` starting from `debugger-agent.c:1349`.
+
+A lot command returns or accepts fixed-length list of value. In these case, such a list is always prefixed with an int value giving its length followed by *length* element of the same type (which needs to be inferred from the context). When such a list is used the term "list" will be used. For clarification, an empty list is thus a single int value equals to 0.
+
+#### Various enumeration value definition
+
+For the record, the following C enumerations define the values used for flags, kind, ... parameters in some commands.
+
+``` c
+typedef enum {
+ EVENT_KIND_VM_START = 0,
+ EVENT_KIND_VM_DEATH = 1,
+ EVENT_KIND_THREAD_START = 2,
+ EVENT_KIND_THREAD_DEATH = 3,
+ EVENT_KIND_APPDOMAIN_CREATE = 4,
+ EVENT_KIND_APPDOMAIN_UNLOAD = 5,
+ EVENT_KIND_METHOD_ENTRY = 6,
+ EVENT_KIND_METHOD_EXIT = 7,
+ EVENT_KIND_ASSEMBLY_LOAD = 8,
+ EVENT_KIND_ASSEMBLY_UNLOAD = 9,
+ EVENT_KIND_BREAKPOINT = 10,
+ EVENT_KIND_STEP = 11,
+ EVENT_KIND_TYPE_LOAD = 12,
+ EVENT_KIND_EXCEPTION = 13,
+ EVENT_KIND_KEEPALIVE = 14,
+ EVENT_KIND_USER_BREAK = 15,
+ EVENT_KIND_USER_LOG = 16
+} EventKind;
+
+typedef enum {
+ SUSPEND_POLICY_NONE = 0,
+ SUSPEND_POLICY_EVENT_THREAD = 1,
+ SUSPEND_POLICY_ALL = 2
+} SuspendPolicy;
+
+typedef enum {
+ MOD_KIND_COUNT = 1,
+ MOD_KIND_THREAD_ONLY = 3,
+ MOD_KIND_LOCATION_ONLY = 7,
+ MOD_KIND_EXCEPTION_ONLY = 8,
+ MOD_KIND_STEP = 10,
+ MOD_KIND_ASSEMBLY_ONLY = 11,
+ MOD_KIND_SOURCE_FILE_ONLY = 12,
+ MOD_KIND_TYPE_NAME_ONLY = 13,
+ MOD_KIND_NONE = 14
+} ModifierKind;
+
+typedef enum {
+ STEP_DEPTH_INTO = 0,
+ STEP_DEPTH_OVER = 1,
+ STEP_DEPTH_OUT = 2
+} StepDepth;
+
+typedef enum {
+ STEP_SIZE_MIN = 0,
+ STEP_SIZE_LINE = 1
+} StepSize;
+
+typedef enum {
+ TOKEN_TYPE_STRING = 0,
+ TOKEN_TYPE_TYPE = 1,
+ TOKEN_TYPE_FIELD = 2,
+ TOKEN_TYPE_METHOD = 3,
+ TOKEN_TYPE_UNKNOWN = 4
+} DebuggerTokenType;
+
+typedef enum {
+ VALUE_TYPE_ID_NULL = 0xf0,
+ VALUE_TYPE_ID_TYPE = 0xf1,
+ VALUE_TYPE_ID_PARENT_VTYPE = 0xf2
+} ValueTypeId;
+
+typedef enum {
+ FRAME_FLAG_DEBUGGER_INVOKE = 1,
+
+ // Use to allow the debugger to display managed-to-native transitions in stack frames.
+ FRAME_FLAG_NATIVE_TRANSITION = 2
+} StackFrameFlags;
+
+typedef enum {
+ INVOKE_FLAG_DISABLE_BREAKPOINTS = 1,
+ INVOKE_FLAG_SINGLE_THREADED = 2,
+
+ // Allow for returning the changed value types after an invocation
+ INVOKE_FLAG_RETURN_OUT_THIS = 4,
+
+ // Allows the return of modified value types after invocation
+ INVOKE_FLAG_RETURN_OUT_ARGS = 8,
+
+ // Performs a virtual method invocation
+ INVOKE_FLAG_VIRTUAL = 16
+} InvokeFlags;
+```
+
+### Command list
+
+Types given in each command comments corresponds to the type described above. When there are additional arguments or multiple values in a command's reply, they are each time described in the order they appear or have to appear in the data part. Not also that there is no kind of separation sequence or added alignement padding between each value.
+
+In all cases, if you ask for a command that doesn't exist, a reply will be sent with an error code of NOT_IMPLEMENTED.
+
+#### Virtual machine commands
+
+| Name | Value | Action and type of reply | Additional parameters | Possible error code returned |
+|:--------------------------|:------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------------------------------------------------------|
+| VERSION | 1 | Returns a mono virtual machine version information (string) followed by two int giving respectively the runtime major and minor version | None | None |
+| ALL_THREADS | 2 | Returns a list of ObjectID each mapping to a System.Threading.Thread instance. | None | None |
+| SUSPEND | 3 | Suspend the VM execution and returns an empty reply | None | None |
+| RESUME | 4 | Resume the VM execution and returns an empty reply | None | NOT_SUSPENDED |
+| EXIT | 5 | Stop VM and returns an empty reply | Ask for a exit code (int) to be used by the VM when it exits | None |
+| DISPOSE | 6 | Clear event requests, resume the VM and disconnect | None | None |
+| INVOKE_METHOD | 7 | Returns a boolean telling if the call was successful followed by an exception object (as a variant) if it was not and by the actual returned value (variant) if it was. | Ask for an ObjectID (id) mapping to a System.Threading.Thread instance, a flags value (int) to pass to the invoke request, the MethodID (id) of the method to invoke, a variant value to be used as *this* (VALUE_TYPE_ID_NULL in case of a valuetype) and a list of variant value representing the parameters of the method. | INVALID_OBJECT, NOT_SUSPENDED, INVALID_METHODID, INVALID_ARGUMENT |
+| SET_PROTOCOL_VERSION | 8 | Returns an empty reply | Ask for two int giving respectively the major and minor version of the procotol to use. | None |
+| ABORT_INVOKE | 9 | Abort the invocation and returns an empty reply | Ask for an ObjectID (id) mapping to a System.Threading.Thread instance and the id (int) of the command packet that set up the invocation to cancel | INVALID_OBJECT, NO_INVOCATION |
+| SET_KEEPALIVE | 10 | Set up the new keep alive value and returns an empty reply | Ask for a timeout value (int) | None |
+| GET_TYPES_FOR_SOURCE_FILE | 11 | Returns a list of TypeID (id) of class defined inside the supplied file name | Ask for a file name (string) and an ignore case flag (byte) although setting it to something different than 0 isn't currently supported. | None |
+| GET_TYPES | 12 | Returns a list of TypeID (id) of type which corresponds to the provided type name | Ask for type name (string) and a ignore case flag (byte) which acts like a boolean value | INVALID_ARGUMENT |
+| INVOKE_METHODS | 13 | Batch invocation of methods | Ask for an ObjectID (id) mapping to a System.Threading.Thread instance, a flags value (int) to pass to the invoke request, the number of methods to invoke (int), and for each method the the MethodID (id) for each method to invoke, a variant value to be used as *this* (VALUE_TYPE_ID_NULL in case of a valuetype) and a list of variant value representing the parameters of the method. | INVALID_OBJECT, NOT_SUSPENDED, INVALID_METHODID, INVALID_ARGUMENT |
+| VM_START_BUFFERING | 14 | Initiates the buffering of reply packets to improve latency. Must be paired with a VM_STOP_BUFFERING command | None | None |
+| VM_STOP_BUFFERING | 15 | Ends the block of buffered commands, must come after a call to VM_START_BUFFERING | None | None |
+
+The main function handling these commands is `vm_commands` and is situated at `debugger-agent.c:5671`
+
+#### Events commands
+
+Events allows the debuggee to act on program execution (stepping) and also to set up things like breakpoints, watchpoints, exception catching, etc.
+
+| Name | Value | Type of reply | Additional parameters | Possible error code returned |
+|:------------------------------|:------|:-----------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------|
+| REQUEST_SET | 1 | Returns the request id (int) | Ask for 3 bytes giving the event kind (EventKind enumeration), suspend policy (SuspendPolicy enumeration) and a list of modifiers which content is context dependent and given in the table below | INVALID_METHODID, INVALID_TYPEID, NO_SEQ_POINT_AT_IL_OFFSET, INVALID_OBJECT, INVALID_ASSEMBLYID |
+| REQUEST_CLEAR | 2 | Clear the requested event and returns an empty reply | Ask for an event type (byte) and a request id (int) | None |
+| REQUEST_CLEAR_ALL_BREAKPOINTS | 3 | Returns an empty reply | None | None |
+
+The main function handling these commands is `event_commands` and is situated at `debugger-agent.c:5916`
+
+Each modifier has the first byte describing the modification it's carrying out and corresponding to the values found in the ModifierKind enumeration. The following table list the remaining body depending on the modification value.
+
+| Mod value | Body |
+|:-----------------|:-----------------------------------------------------------------------------------------------------------------------------------------------|
+| COUNT | a MethodID (id) |
+| LOCATION_ONLY | a MethodID (id) and a location information (long) |
+| STEP | A thread id, size of the step (int) corresponding to the StepSize enumeration and depth of it (int) corresponding to the StepDepth enumeration |
+| THREAD_ONLY | A thread id |
+| EXCEPTION_ONLY | A TypeID representing a exception type and two byte values setting respectively the caught and uncaught filter |
+| ASSEMBLY_ONLY | A list of AssemblyID (id) |
+| SOURCE_FILE_ONLY | A list of source file name (string) |
+| TYPE_NAME_ONLY | A list of type name (string) |
+| NONE | |
+
+#### Thread commands
+
+Each command requires at least one ObjectID (of type id) parameter mapping to a thread instance before any additional parameter the command may require.
+
+| Name | Value | Type of reply | Additional parameters | Possible error code returned |
+|:---------------|:------|:------------------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------|:-----------------------------|
+| GET_FRAME_INFO | 1 | Returns a list of quadruplet of frame ID (int), MethodID (id), IL offset (int) and frame flags (byte) | Ask for a start frame (currently other value than 0 aren't supported) as an int and a length as a int | INVALID_OBJECT |
+| GET_NAME | 2 | Returns the name of the thread as a string | None | INVALID_OBJECT |
+| GET_STATE | 3 | Return the thread state as an int | None | INVALID_OBJECT |
+| GET_INFO | 4 | Returns a byte value telling if the thread is a threadpool thread (1) or not (0) | None | INVALID_OBJECT |
+| GET_ID | 5 | Returns the thread id (address of the object) as a long | None | INVALID_OBJECT |
+| GET_TID | 6 | Returns the proper thread id (or TID) as a long | None | INVALID_OBJECT |
+| SET_IP | 7 | Set the location where execution will return when this thread is resumed | Thread ID (int), Method ID (long), IL offset (long) | INVALID_ARGUMENT |
+
+The main function handling these commands is `thread_commands` and is situated at `debugger-agent.c:6991`
+
+#### AppDomains commands
+
+| Name | Value | Type of reply | Additional parameters | Possible error code returned |
+|:-------------------|:------|:----------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------|:---------------------------------|
+| GET_ROOT_DOMAIN | 1 | Returns the DomainID of the root domain | None | None |
+| GET_FRIENDLY_NAME | 2 | Returns the friendly name as a string of the provided DomainID | Ask for a DomainID (id) | INVALID_DOMAINID |
+| GET_ASSEMBLIES | 3 | Returns a list of AssemblyID contained inside this AppDomain | Ask for a DomainID (id) | INVALID_DOMAINID |
+| GET_ENTRY_ASSEMBLY | 4 | Returns the entry AssemblyID of this domain | Ask for a DomainID (id) | INVALID_DOMAINID |
+| CREATE_STRING | 5 | Returns the ObjectID of the created string | Ask for a DomainID (id) where to create the new string and a string typed value to put inside the domain | INVALID_DOMAINID |
+| GET_CORLIB | 6 | Returns the AssemblyID of the load corlib inside this AppDomain | Ask for a DomainID (id) | INVALID_DOMAINID |
+| CREATE_BOXED_VALUE | 7 | Returns the ObjectID of the boxed value | Ask for a DomainID (id), TypeID of the type that is going to be boxed and a variant value which is going to be put into the boxed value | INVALID_DOMAINID, INVALID_TYPEID |
+
+The main function handling these commands is `domain_commands` and is situated at `debugger-agent.c:6104`
+
+#### Assembly commands
+
+Each command requires at least one AssemblyID (of type id) parameter before any additional parameter the command may require.
+
+| Name | Value | Type of reply | Additional parameters | Possible error code returned |
+|:--------------------|:------|:------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------|:-----------------------------|
+| GET_LOCATION | 1 | Returns the filename (string) of image associated to the assembly | None | INVALID_ASSEMBLYID |
+| GET_ENTRY_POINT | 2 | Returns the MethodID (id) of the entry point or a 0 id if there is none (in case of dynamic assembly or library for instance) | None | INVALID_ASSEMBLYID |
+| GET_MANIFEST_MODULE | 3 | Returns the ModuleID (id) of the assembly | None | INVALID_ASSEMBLYID |
+| GET_OBJECT | 4 | Returns the ObjectID of the AssemblyID object instance | None | INVALID_ASSEMBLYID |
+| GET_TYPE | 5 | Returns the TypeID of the found type or a null id if it wasn't found | Ask for a type information in form of a string and a byte value to tell if case should be ignored (1) or not (0) | INVALID_ASSEMBLYID |
+| GET_NAME | 6 | Return the full name of the assembly as a string | None | INVALID_ASSEMBLYID |
+
+The main function handling these commands is `assembly_commands` and is situated at `debugger-agent.c:6203`
+
+#### Module commands
+
+| Name | Value | Type of reply | Additional parameters | Possible error code returned |
+|:--------------------|:------|:----------------------------------------------------------------------------------------------------------------|:------------------------|:-----------------------------|
+| CMD_MODULE_GET_INFO | 1 | Returns the following strings: basename of the image, scope name, full name, GUID and the image AssemblyID (id) | Ask for a ModuleID (id) | None |
+
+The main function handling these commands is `module_commands` and is situated at `debugger-agent.c:6295`
+
+#### Method commands
+
+Each command requires at least one MethodID (of type id) parameter before any additional parameter the command may require.
+
+| Name | Value | Type of reply | Additional parameters | Possible error code returned |
+|:--------------------|:------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------|:-----------------------------------|
+| GET_NAME | 1 | Returns a string of the method name | None | INVALID_METHODID |
+| GET_DECLARING_TYPE | 2 | Returns a TypeID of the declaring type for this method | None | INVALID_METHODID |
+| GET_DEBUG_INFO | 3 | Returns the code size of the method (int), source file name (string) and a list of tuple of IL offset (int) and line numbers (int) for the method | None | INVALID_METHODID |
+| GET_PARAM_INFO | 4 | Returns the call convention (int), parameter count (int), generic parameter count (int), TypeID of the returned value (id), *parameter count* TypeID for each parameter type and finally *parameter count* parameter name (string) for each parameter. | None | INVALID_METHODID |
+| GET_LOCALS_INFO | 5 | Returns the number of locals (int) followed by the TypeID (id) for each locals, followed by the name (string) of each locals (empty string if there is none) and finally followed by the scope of each locals which is a tuple of int giving the start address and end offset. | None | INVALID_METHODID |
+| GET_INFO | 6 | Returns 3 int representing respectively the method flags, implementation flags and token | None | INVALID_METHODID |
+| GET_BODY | 7 | Returns a list of byte corresponding to the method IL code. | None | INVALID_METHODID |
+| RESOLVE_TOKEN | 8 | Returns a variant value corresponding to the provided token | Ask for a token value (int) | INVALID_METHODID |
+| GET_CATTRS | 9 | Returns the custom attributes for the methods | Method ID, attribute-type ID | INVALID_METHODID,LOADER_ERROR |
+| MAKE_GENERIC_METHOD | 10 | Makes a generic version of the method | Method ID, number of type arguments (int), TypeID for each type argument (int) | INVALID_ARGUMENT, INVALID_METHODID |
+
+The main functions handling these commands are `method_commands` and `method_commands_internal` and are situated at `debugger-agent.c:6968` and `debugger-agent.c:6968` respectively.
+
+#### Type commands
+
+Each command requires at least one TypeID (of type id) parameter before any additional parameter the command may require.
+
+| Name | Value | Type of reply | Additional parameters | Possible error code returned |
+|:--------------------|:------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------------------------------------|
+| GET_INFO | 1 | Returns the following informations about the type in that order: namespace (string), class name (string), full name (string), AssemblyID (id), ModuleID (id), TypeID (id), TypeID (id) of underlying type (or a 0 id if there is none), type token (int), type rank (byte), type flags (int), underlying byval type (byte) flags (see after table) and a list of nested type TypeID | None | INVALID_TYPEID |
+| GET_METHODS | 2 | Returns a list of MethodID corresponding to each of the method of the type | None | INVALID_TYPEID |
+| GET_FIELDS | 3 | Returns list of quadruplet of FieldID (id), field name (string), field TypeID (id), field attributes (int) | None | INVALID_TYPEID |
+| GET_VALUES | 4 | Returns a number of variant value equals to the number of FieldID that was passed as parameter. If the field had a ThreadStatic attribute applied to it, value fetched are from the current thread point of view. | Ask for a list of FieldID representing this type static fields to the the value of. Only static field are supported. | INVALID_TYPEID, INVALID_FIELDID |
+| GET_OBJECT | 5 | Returns an ObjectID corresponding to the type instance | None | INVALID_TYPEID |
+| GET_SOURCE_FILES | 6 | Returns the same output than GET_SOURCE_FILES_2 except only the basename of each path is returned | None | INVALID_TYPEID |
+| SET_VALUES | 7 | Returns an empty response | Ask for a list of tuple of FieldID and variant value. Only pure static field can be set (i.e. with no extra attribute like ThreadStatic). | INVALID_TYPEID, INVALID_FIELDID |
+| IS_ASSIGNABLE_FROM | 8 | Returns a boolean equals to true if the type is assignable from the other provided type, false otherwise | Ask for an extra TypeID | INVALID_TYPEID |
+| GET_PROPERTIES | 9 | Returns a list of quadruplet of FieldID (id), get accessor MethodID (string), set accessor MethodID (id), property attributes (int) | None | INVALID_TYPEID |
+| GET_CATTRS | 10 | Returns a list of custom attribute applied on the type. Custom attribute definition is given below. | Ask for a TypeID of an custom attribute type | INVALID_TYPEID |
+| GET_FIELD_CATTRS | 11 | Returns a list of custom attributes of a type's field. Custom attribute definition is given below. | Ask for a FieldID of one the type field and a TypeID of an custom attribute type | INVALID_TYPEID, INVALID_FIELDID |
+| GET_PROPERTY_CATTRS | 12 | Returns a list of custom attributes of a type's property. Custom attribute definition is given below. | Ask for a PropertyID of one the type field and a TypeID of an custom attribute type | INVALID_TYPEID, INVALID_PROPERTYID |
+| GET_SOURCE_FILES_2 | 13 | Returns a list of source file full paths (string) where the type is defined | None | INVALID_TYPEID |
+| GET_VALUES_2 | 14 | Returns a number of variant value equals to the number of FieldID that was passed as parameter. If the field had a ThreadStatic attribute applied to it, value fetched are from the thread parameter point of view. | Ask for an ObjectID representing a System.Thread instance and a list of FieldID representing this type static fields to the the value of. Only static field are supported. | INVALID_OBJECT, INVALID_TYPEID, INVALID_FIELDID |
+
+The main functions handling these commands are `type_commands` and `type_commands_internal` and are situated at `debugger-agent.c:6726` and `debugger-agent.c:6403` respectively.
+
+Byval flags is an indication of the type attribute for a parameter when it's passed by value. A description of these flags follows:
+
+| byte 1 | byte 2 | byte 3 | byte 4 | byte 5 | byte 6 | byte 7 | byte 8 |
+|:------------------|:--------------------|:----------------|:------------------|:-------|:-------|:-------|:-------|
+| Is a pointer type | Is a primitive type | Is a value type | Is an enumeration | Unused | Unused | Unused | Unused |
+
+Custom attribute definition is as follows: MethodID of the attribute ctor, a list of variant objects representing the typed arguments of the attribute prepended by a length attribute (int) and another list representing named arguments of which elements are either tuple of the constant 0x53 followed by a variant value (in case the named argument is a field) or a triplet of the constant 0x54 followed by a PropertyID followed by a variant value (in case the named argument is a property). In both list case, an empty list is simply one int of value 0.
+
+#### Stackframe commands
+
+Each command requires at least one ObjectID (of type id) parameter mapping to a System.Threading.Thread instance and a FrameID (of type id) before any additional parameter the command may require.
+
+| Name | Value | Type of reply | Additional parameters | Possible error code returned |
+|:-----------|:------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------|
+| GET_VALUES | 1 | Returns a list of miscelleanous typed values. If the position information was negative, the value corresponds to a parameter and if it was positive to a local variable. | Ask for a list of position (int) information. | INVALID_OBJECT, INVALID_FRAMEID, ABSENT_INFORMATION |
+| GET_THIS | 2 | Returns the *this* value prepended by a single byte value describing its type, or the special TYPE_ID_NULL (byte) value which is equal to 0xf0 in case there is no *this* parameter. | None | INVALID_OBJECT, INVALID_FRAMEID, ABSENT_INFORMATION |
+| SET_VALUES | 3 | Returns an empty reply | Ask for a list of pair of position (int) information and variant whose value is going to be used. | INVALID_OBJECT, INVALID_FRAMEID, ABSENT_INFORMATION, INVALID_ARGUMENT |
+
+The main function handling these commands is `frame_commands` and is situated at `debugger-agent.c:7082`
+
+#### Array commands
+
+Each command requires at least one ObjectID (of type id) parameter mapping to a System.Array instance before any additional parameter the command may require.
+
+| Name | Value | Type of reply | Additional parameters | Possible error code returned |
+|:-----------|:------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------|
+| GET_LENGTH | 1 | Returns an int corresponding to the array rank followed by a set of int pair corresponding respectively to the length and lower bound of each of the array dimensions. In case of a single dimensional zero-based array, the returned data amount to 3 int values with the second being the total length of the array and the third one being 0. | None | INVALID_OBJECT |
+| GET_VALUES | 2 | Returns a list of *length* elements which individual size in bytes depends on the underlying type of the System.Array instance. | Ask for an index (int) and a length (int) to determine the range of value to return | INVALID_OBJECT |
+| SET_VALUES | 3 | Return an empty reply | Ask for an index (int) and a length (int) to determine the range of value to set and a *length* number of trailing values whose type and byte size match those of the underlying type of the System.Array instance. | INVALID_OBJECT |
+
+The main function handling these commands is `vm_commands` and is situated at `debugger-agent.c:5671`
+
+#### String commands
+
+Each command requires at least one ObjectID (of type id) parameter mapping to a System.String instance before any additional parameter the command may require.
+
+| Name | Value | Type of reply | Additional parameters | Possible error code returned |
+|:-----------|:------|:-------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------|:---------------------------------|
+| GET_VALUE | 1 | Returns a UTF8-encoded string corresponding to the System.String instance with its length prepended as a int value | None | INVALID_OBJECT |
+| GET_LENGTH | 2 | Returns the length of a UTF8-encoded string corresponding to the System.String instance as an int value | None | INVALID_OBJECT |
+| GET_CHARS | 3 | Returns *length* short values each encoding a character of the string slice | Ask for a start index (long) and a length parameter (long) of the string slice to take. | INVALID_OBJECT, INVALID_ARGUMENT |
+
+The main function handling these commands is `string_commands` and is situated at `debugger-agent.c:7293`
+
+#### Object commands
+
+Each command requires at least one ObjectID (of type id) parameter before any additional parameter the command may require.
+
+| Name | Value | Type of reply | Additional parameters | Possible error code returned |
+|:-------------|:------|:------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------|:------------------------------------------|
+| GET_TYPE | 1 | Returns the TypeID as an id | None | INVALID_OBJECT |
+| GET_VALUES | 2 | Returns *length* values of miscellaneous type and size corresponding to the underlying type of each queried field | Ask for a list of FieldID to fetch value of | INVALID_OBJECT, UNLOADED, INVALID_FIELDID |
+| IS_COLLECTED | 3 | Returns an int equals to 1 if the object has been collected by GC, 0 otherwise | None | None |
+| GET_ADDRESS | 4 | Returns a long value corresponding to the address where the object is stored in memory | None | INVALID_OBJECT |
+| GET_DOMAIN | 5 | Returns an id corresponding to the DomainID the object is located in | None | INVALID_OBJECT |
+| SET_VALUES | 6 | Returns an empty reply | Ask for a list of tuple of FieldID (id) and of the value that should be set to it | INVALID_OBJECT, UNLOADED, INVALID_FIELDID |
+
+The main function handling these commands is `object_commands` and is situated at `debugger-agent.c:7318`
+
+#### Composite commands
+
+| Name | Value | Description |
+|:----------|:------|:-------------------------------------------------------------------------|
+| COMPOSITE | 100 | This command is actually part of the event command set and is used for ? |
+
+## Differences with JDWP
+
+- Handshake ASCII sequence is DWP-Handshake instead of JDWP-Handshake
+- Some new Mono specific command set such as AppDomain, Assembly or Module and removal/renaming of some Java specific set such as InterfaceType, ThreadGroupReference, ClassLoaderReference, etc.
+- Mono SDB protocol has its own specific ID types related to the new command sets.
+- SDB protocol has less error code although some are Mono-specific like "No Invocation", "Absent Informations" and "No seq point at IL offset" codes.
diff --git a/docs/design/mono/web/soft-debugger.md b/docs/design/mono/web/soft-debugger.md
new file mode 100644
index 000000000000..4a9dbb36f542
--- /dev/null
+++ b/docs/design/mono/web/soft-debugger.md
@@ -0,0 +1,91 @@
+# Soft-Mode Debugger
+
+The Mono Soft Debugger is a new debugging framework for Mono. Unlike regular debuggers which act as all-knowing and controlling programs that control a separate process, the Mono Soft Debugger is actually a cooperative debugger that is built into the Mono runtime.
+
+Applications communicate with the Mono runtime and request debugging operations to be performed on the target process.
+
+ The Mono Soft Debugger first became available with Mono 2.6 and is primarily used today with [Mono on the iPhone](http://monotouch.net) and is used from the [MonoDevelop IDE](http://monodevelop.com).
+
+Architecture
+------------
+
+The following diagram is useful in the discussion of the soft debugger:
+
+[](images/0911030528Mp6F5SHL.png)
+
+The soft debugger lives inside the Mono runtime. Debuggers communicate with this component with a compact protocol over a socket connection. For ease of use the protocol has been encapsulated in the Mono.Debugger.Soft.dll API which different IDEs can use to communicate with the target.
+
+The soft debugger work both with Just-in-Time compiled code, and with [batch compiled code](/docs/advanced/aot/) allowing it to debug both regular Mono applications on a desktop, or applications on devices like the iPhone or the [PlayStation 3](/docs/about-mono/supported-platforms/playstation3/).
+
+### Debugger Agent
+
+The debugger agent is a module inside the mono runtime which offers debugging services to client programs.
+
+### Wire Protocol
+
+Clients communicate with the agent using a wire protocol over a socket transport. Read our [Soft Debugger Wire Protocol](/docs/advanced/runtime/docs/soft-debugger-wire-format/) document for details about the protocol.
+
+The wire protocol is inspired by the [Java Debug Wire Protocol](http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwp-spec.html).
+
+### Client library
+
+The client library is a C# assembly which uses the wire protocol to communicate with the debugger agent running inside the mono runtime. It is based on the [Java Debug Interface](http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdi/). The assembly is named Mono.Debugger.Soft.dll, and its source is in mcs/class/Mono.Debugger.Soft.
+
+Implementation
+--------------
+
+### Agent
+
+The source code is in mini/debugger-agent.{h,c}. Unlike the JDWP agent in Java, the debugger agent is tightly integrated with the mono runtime because mono doesn't have a tool interface with similar capabilities as JVMTI in Java.
+
+#### Design
+
+The design for the agent was to choose solutions which were easy to implement, they can be improved later. This means that some things like step out/over can be very slow, the code generated by the JIT when debugging is enabled is larger/slower etc.
+
+#### The debugger thread
+
+The agent starts its own thread which it uses to communicate with clients using the wire protocol.
+
+#### Event handling
+
+On startup, the agent registers callbacks for events using the mono profiler interface. When a callback is called, it searches the list of event requests for a request matching the event type. If one is found, the event is sent to the client using the wire protocol.
+
+#### Suspend/Resume
+
+Suspending/Resuming the runtime is the most complex part of the debugger agent. There are many complications: - threads running managed code/native code/transitioning between the two. - threads starting up/terminating. - multiple suspend/resume operations happening in parallel.
+
+Threads running native code can't be suspended, because they can hold locks which are needed by the debugger and the rest of the runtime to function. So they are left running, and are only suspended when they enter managed code. We save enough state at managed-\>native transitions to be able to produce stack traces and examine the state of stack frames. However, debugger invocations are not supported on threads which are running managed code, so property evaluation is not possible on these threads.
+
+A suspend can be started by a normal runtime thread when it receives an event which asks for the runtime to suspend, or it can be started by the debugger thread in response to a VM.Suspend command. In contrast, a resume can only be started by the debugger thread in response to a VM.Resume command.
+
+Threads running managed code are suspended by turning on single stepping, and suspending the thread when it reaches the single step event handler. Threads running native code are treated as suspended.
+
+A suspend can be started by calling suspend_vm (), which is an async operation. This means that when the client receives an event, the runtime might not be entirely suspended yet, so code which needs the runtime to be suspended like the stack frame processing code needs to call wait_for_suspend (). After starting a suspend, the thread needs to suspend itself by calling suspend_current ().
+
+#### Sequence points
+
+A sequence point is an IL offset where the program can be stopped and its state can be examined. Currently the debugger determines sequence points automatically. A sequence point is placed at the places:
+
+- IL offsets where the IL stack is empty. This generally corresponds to the end of C# statements.
+- IL offsets which contain the NOP IL instructions. This can be used by a compiler to insert extra sequence points, like between nested calls.
+- IL offsets which have a corresponding line number entry in the .mdb file.
+
+The mdbdump tool in mcs/tools/mdbdump can be used to examine the line number tables inside an .mdb file.
+
+A sequence point is represented by the JIT opcode OP_SEQ_POINT. The JIT backends generate code from this opcode which implements single stepping/breakpoints.
+
+#### Single Stepping
+
+The implementation of single stepping is target specific. On most platforms, it is implemented by allocating a memory page and having the implementation of OP_SEQ_POINT read from that page. Single stepping is then turned on by read-protecting that page, causing the memory read to turn into a SIGSEGV or similar signal. The signal handler needs to determine whenever the signal was caused by access to this page, and if it is, transfer control to the single step handler code in the debugger agent.
+
+Step over/out is implemented by single stepping repeatedly until the condition becomes true (i.e. we reach a different line/parent frame).
+
+#### Breakpoints
+
+Breakpoints are usually implemented similarly to single stepping, by reading from a memory page. OP_SEQ_POINT generates a few nops to act as a placeholder, then the code to read from the trigger page is written to the JITted code when the breakpoint is enabled, and changed back to nops when the breakpoint is disabled.
+
+#### AOT support
+
+AOTed code can be debugged by compiling it with the 'soft-debug' aot option, i.e: mono --debug --aot=soft-debug foo.dll
+
+In the AOT case, the code can'be be patched at runtime, so breakpoints are implemented by reading from per-method table with one entry per sequence point, which is either NULL or points to the breakpoint trigger page.
diff --git a/docs/design/mono/web/thread-safety.md b/docs/design/mono/web/thread-safety.md
new file mode 100644
index 000000000000..6449866acff1
--- /dev/null
+++ b/docs/design/mono/web/thread-safety.md
@@ -0,0 +1,129 @@
+# Thread Safety/Synchronization
+
+Thread safety of metadata structures
+------------------------------------
+
+### Synchronization of read-only data
+
+Read-only data is data which is not modified after creation, like the actual binary metadata in the metadata tables.
+
+There are three kinds of threads with regards to read-only data:
+
+- readers
+- the creator of the data
+- the destroyer of the data
+
+Most threads are readers.
+
+- synchronization between readers is not necessary
+- synchronization between the writers is done using locks.
+- synchronization between the readers and the creator is done by not exposing the data to readers before it is fully constructed.
+- synchronization between the readers and the destroyer: TBD.
+
+### Deadlock prevention plan
+
+Hold locks for the shortest time possible. Avoid calling functions inside locks which might obtain global locks (i.e. locks known outside this module).
+
+### Locks
+
+#### Simple locks
+
+There are a lot of global data structures which can be protected by a 'simple' lock. Simple means:
+
+- the lock protects only this data structure or it only protects the data structures in a given C module. An example would be the appdomains list in domain.c
+- the lock can span many modules, but it still protects access to a single resource or set of resources. An example would be the image lock, which protects all data structures that belong to a given MonoImage.
+- the lock is only held for a short amount of time, and no other lock is acquired inside this simple lock. Thus there is no possibility of deadlock.
+
+Simple locks include, at least, the following :
+
+- the per-image lock acquired by using mono_image_(un)lock functions.
+- the threads lock acquired by using mono_threads_(un)lock.
+
+#### The loader lock
+
+This locks is held by class loading routines and any global synchronization routines. This is effectively the runtime global lock. Other locks can call code that acquire the loader lock out of order if the current thread already owns it.
+
+#### The domain lock
+
+Each appdomain has a lock which protects the per-domain data structures.
+
+#### The domain jit code hash lock
+
+This per-domain lock protects the JIT'ed code of each domain. Originally we used the domain lock, but it was split to reduce contention.
+
+#### Allocation locks and foreign locks
+
+Mono features a few memory allocation subsystems such as: a lock-free allocator, the GC. Those subsystems are designed so they don't rely on any of the other subsystems in the runtime. This ensures that locking within them is transparent to the rest of the runtime and are not covered here. It's the same rule when dealing with locking that happens within libc.
+
+### The locking hierarchy
+
+It is useful to model locks by a locking hierarchy, which is a relation between locks, which is reflexive, transitive, and antisymmetric, in other words, a lattice. If a thread wants to acquire a lock B, while already holding A, it can only do it if A \< B. If all threads work this way, then no deadlocks can occur.
+
+Our locking hierarchy so far looks like this (if lock A is above lock B, then A \< B):
+
+
+ \
+
+ \ \ \
+
+
+For example: if a thread wants to hold a domain jit lock, a domain lock and the loader lock, it must acquire them in the order: loader lock, domain lock, domain jit lock.
+
+### Notes
+
+Some common scenarios:
+
+- if a function needs to access a data structure, then it should lock it itself, and do not count on its caller locking it. So for example, the image-\>class_cache hash table would be locked by mono_class_get().
+
+- there are lots of places where a runtime data structure is created and stored in a cache. In these places, care must be taken to avoid multiple threads creating the same runtime structure, for example, two threads might call mono_class_get () with the same class name. There are two choices here:
+
+
+
+
+
+ if (created) {
+
+ return item
+ }
+
+
+
+
+This is the easiest solution, but it requires holding the lock for the whole time which might create a scalability problem, and could also lead to deadlock.
+
+
+
+
+ if (created) {
+ return item
+ }
+
+
+
+ if (created) {
+ /* Another thread already created and stored the same item */
+
+
+ return orig item
+ }
+ else {
+
+
+ return item
+ }
+
+This solution does not present scalability problems, but the created item might be hard to destroy (like a MonoClass). If memory is allocated from a mempool, that memory is leaked, but the leak is very rare and it is bounded.
+
+- lazy initialization of hashtables etc. is not thread safe
+
+[Original version of this document in git](https://github.com/mono/mono/blob/8f91e420d7fbbab7da758e57160d1d762129f38a/docs/thread-safety.txt)
+
+### The Lock Tracer
+
+Mono now have a lock tracer that allows to record the locking behavior of the runtime during execution and later verify it's correctness.
+
+To enable lock tracer support define LOCK_TRACER in mono/mono/metadata/lock-tracer.h and recompile mono. To enable it at runtime define the MONO_ENABLE_LOCK_TRACER environment variable.
+
+The lock tracer produces a file in the same directory of the application, it's named 'lock.ZZZ' where ZZZ is the pid of the mono process.
+
+After producing such lock file, run the trace decoder that can be found in mono/data/lock-decoder. It currently only works on linux and macOS, it requires binutils to be installed. The decoder will report locking errors specifying the functions that caused it.
diff --git a/docs/design/mono/web/trampolines.md b/docs/design/mono/web/trampolines.md
new file mode 100644
index 000000000000..a1ad2b70b5b3
--- /dev/null
+++ b/docs/design/mono/web/trampolines.md
@@ -0,0 +1,75 @@
+# Trampolines
+
+Trampolines are small, hand-written pieces of assembly code used to perform various tasks in the mono runtime. They are generated at runtime using the native code generation macros used by the JIT. They usually have a corresponding C function they can fall back to if they need to perform a more complicated task. They can be viewed as ways to pass control from JITted code back to the runtime.
+
+The common code for all architectures is in mini-trampolines.c, this file contains the trampoline creation functions plus the C functions called by the trampolines. The tramp-\.c files contain the arch-dependent code which creates the trampolines themselves.
+
+Most, but not all trampolines consist of two parts:
+
+- a generic part containing most of the code. This is created by the mono_arch_create_trampoline_code () function in tramp-\.c. Generic trampolines can be large (1kb).
+- a specific part whose job is to call the generic part, passing in a parameter. The parameter to pass and the method by it is passed depends on the type of the trampoline. Specific trampolines are created by the mono_arch_create_specific_trampoline () function in tramp-\.c. Specific trampolines are small, since the runtime creates lots of them.
+
+The generic part saves the machine state to the stack, and calls one of the trampoline functions in mini-trampolines.c with the state, the call site, and the argument passed by the specific trampoline. After the C function returns, it either returns normally, or branches to the address returned by the C function, depending on the trampoline type.
+
+Trampoline types are given by the MonoTrampolineType enumeration in [mini.h](https://github.com/mono/mono/blob/main/mono/mini/mini.h).
+
+The platform specific code for trampolines is in the file tramp-\.c for each architecture, while the cross platform code is in mini-trampolines.c. There are two types of functions in mini-trampolines.c:
+
+- The actual C functions called by the trampolines.
+- Functions to create the different trampolines types.
+
+Trampoline creation functions have the following signature:
+
+``` bash
+gpointer
+mono_arch_create_foo_trampoline (, MonoTrampInfo **info, gboolean aot)
+```
+
+The function should return a pointer to the newly created trampoline, allocating memory from either the global code manager, or from a domain's code manager. If INFO is not NULL, it is set to a pointer to a MonoTrampInfo structure, which contains information about the trampoline, like its name, unwind info, etc. This is used for two purposes:
+
+- Saving the trampoline info an AOT image in 'full-aot' mode.
+- Saving debug info about the trampoline in XDEBUG mode.
+
+### JIT Trampolines
+
+These trampolines are used to JIT compile a method the first time it is called. When the JIT compiles a call instruction, it doesn't compile the called method right away. Instead, it creates a JIT trampoline, and emits a call instruction referencing the trampoline. When the trampoline is called, it calls mono_magic_trampoline () which compiles the target method, and returns the address of the compiled code to the trampoline which branches to it. This process is somewhat slow, so mono_magic_trampoline () tries to patch the calling JITted code so it calls the compiled code instead of the trampoline from now on. This is done by mono_arch_patch_callsite () in tramp-\.c.
+
+### Virtual Call Trampolines
+
+There is one virtual call trampoline per vtable slot index. The trampoline uses this index plus the 'this' argument which is passed in a fixed register/stack slots by the managed calling convention to obtain the virtual method which needs to be compiled. It then patches the vtable slot with the address of the newly compiled method.
+
+\
+
+### Jump Trampolines
+
+Jump trampolines are very similar to JIT trampolines, they even use the same mono_magic_trampoline () C function. They are used to implement the LDFTN and the JMP IL opcodes.
+
+### Class Init Trampolines
+
+These trampolines are used to implement the type initialization sematics of the CLI spec. They call the mono_class_init_trampoline () C function which executes the class initializer of the class passed as the trampoline argument, then replaces the code calling the class init trampoline with NOPs so it is not executed anymore.
+
+### Generic Class Init Trampoline
+
+This is similar to the class init trampolines, but is used for initalizing classes which are only known at run-time, in generic-shared code. It receives the class to be initialized in a register instead of from a specific trampoline. This means there is only one instance of this trampoline.
+
+### RGCTX Lazy Fetch Trampolines
+
+These are used for fetching values from a runtime generic context, lazily initializing the values if they do not exist yet. There is one instance of this trampoline for each offset value.
+
+### AOT Trampolines
+
+These are similar to the JIT trampolines but instead of receiving a MonoMethod to compile, they receive an image+token pair. If the method identified by this pair is also AOT compiled, the address of its compiled code can be obtained without loading the metadata for the method.
+
+### AOT PLT Trampolines
+
+These trampolines handle calls made from AOT code though the PLT.
+
+### Delegate Trampolines
+
+These trampolines are used to handle the first call made to the delegate though its Invoke method. They call mono_delegate_trampoline () which creates a specialized calling sequence optimized to the delegate instance before calling it. Further calls will go through to this optimized code sequence.
+
+### Monitor Enter/Exit Trampolines
+
+These trampolines implement the fastpath of Monitor.Enter/Exit on some platforms.
+
+\
diff --git a/docs/infra/automation.md b/docs/infra/automation.md
index 6b15e2a91716..a4ed601cf33e 100644
--- a/docs/infra/automation.md
+++ b/docs/infra/automation.md
@@ -1,13 +1,9 @@
## Automation
-### Fabric Bot
+### Policy Service Bot
-This repository uses Fabric Bot to automate issue and pull request management. All automation rules are defined in the [`.github/fabricbot.json`](../../.github/fabricbot.json) file.
+This repository uses the Policy Service bot to automate issue and pull request management. All automation rules are defined in the [`.github/policies`](../../.github/policies) folder.
#### Notifications
-You are welcome to enable notifications for yourself for one or more areas. You will be tagged whenever there are new issues and PR's in the area. You do not need to have commit access for this. To add or remove notifications for yourself, please offer a PR that edits the "mentionees" value for that area. [Here is an example](https://github.com/dotnet/runtime/commit/c28b13f0cf4e2127a74285b65188413ca7e677d4).
-
-#### Other changes
-
-For any other changes, you will need access to the [`Fabric Bot portal`](https://portal.fabricbot.ms/bot/) which is only available to Microsoft employees at present. Ensure you are signed out from the portal, choose "Import Configuration" option and make changes using the editor. It's necessary to use the portal because there is at present no published JSON schema for the configuration format.
+You are welcome to enable notifications for yourself for one or more areas. You will be tagged whenever there are new issues and PR's in the area. You do not need to have commit access for this. To add or remove notifications for yourself, please offer a PR that edits the "mentionees" value for that area in the policy YAML file.
diff --git a/docs/project/glossary.md b/docs/project/glossary.md
index c1ff2d29db01..8e1de1bef964 100644
--- a/docs/project/glossary.md
+++ b/docs/project/glossary.md
@@ -25,6 +25,7 @@ terminology.
| EE | [Execution Engine](https://docs.microsoft.com/dotnet/standard/managed-execution-process#running_code). |
| GC | [Garbage Collector](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/garbage-collection.md). |
| IBC | Instrumented Block Counts - used as extension (`*.ibc`) for old PGO files. |
+| IJW | "It Just Works" - Codename for [C++/CLI](https://learn.microsoft.com/cpp/dotnet/dotnet-programming-with-cpp-cli-visual-cpp) managed/native interop |
| IPC | Inter-Process Communication. |
| IL | Intermediate Language. Equivalent to CIL, also equivalent to [MSIL](https://docs.microsoft.com/dotnet/standard/managed-execution-process#compiling-to-msil). |
| JIT | [Just-in-Time](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/jit/ryujit-overview.md) compiler. RyuJIT is the code name for the next generation Just-in-Time(aka "JIT") for the .NET runtime. |
diff --git a/docs/project/list-of-diagnostics.md b/docs/project/list-of-diagnostics.md
index 4cae3a85a87d..9ad0f02f5f88 100644
--- a/docs/project/list-of-diagnostics.md
+++ b/docs/project/list-of-diagnostics.md
@@ -108,6 +108,7 @@ The PR that reveals the implementation of the ``/``/``
The `corflags.exe` tool that ships with the .NET Framework SDK can show whether a binary is delay-signed or strong-named. For a delay-signed assembly it may show:
diff --git a/docs/workflow/building/coreclr/macos-instructions.md b/docs/workflow/building/coreclr/macos-instructions.md
index 8deaf4578bcc..7ac0d0c6e0f8 100644
--- a/docs/workflow/building/coreclr/macos-instructions.md
+++ b/docs/workflow/building/coreclr/macos-instructions.md
@@ -33,6 +33,16 @@ It is possible to get a macOS ARM64 build using an Intel x64 Mac and vice versa,
The Core_Root provides one of the main ways to test your build. Full instructions on how to build it in the [CoreCLR testing doc](/docs/workflow/testing/coreclr/testing.md), and we also have a detailed guide on how to use it for your own testing in [its own dedicated doc](/docs/workflow/testing/using-corerun-and-coreroot.md).
+## Debugging information
+
+The build process puts native component symbol and debugging information into `.dwarf` files, one for each built binary. This is not the native format used by macOS, and debuggers like LLDB can't automatically find them. The native format used by macOS is `.dSYM` bundles. To build `.dSYM` bundles and get a better inner-loop developer experience on macOS (e.g., have the LLDB debugger automatically find program symbols and display source code lines, etc.), build as follows:
+
+```bash
+./build.sh --subset clr --cmakeargs "-DCLR_CMAKE_APPLE_DSYM=TRUE"
+```
+
+(Note: converting the entire build process to build and package `.dSYM` bundles on macOS by default is tracked by [this](https://github.com/dotnet/runtime/issues/92911) issue.)
+
## Native Sanitizers
CoreCLR can be built with native sanitizers like AddressSanitizer to help catch memory safety issues. To build the project with native sanitizers, add the `-fsanitize address` argument to the build script like the following:
diff --git a/docs/workflow/building/coreclr/nativeaot.md b/docs/workflow/building/coreclr/nativeaot.md
index 2a712ca84448..ec70d809a14e 100644
--- a/docs/workflow/building/coreclr/nativeaot.md
+++ b/docs/workflow/building/coreclr/nativeaot.md
@@ -78,8 +78,6 @@ You should now be able to publish the project for Wasm: `dotnet publish --self-c
The paths to major components can be overridden using `IlcToolsPath`, `IlcSdkPath`, `IlcFrameworkPath`, `IlcFrameworkNativePath` and `IlcMibcPath` properties for `dotnet publish`. For example, `/p:IlcToolsPath=\artifacts\bin\coreclr\windows.x64.Debug\ilc` can be used to override the compiler with a local debug build for troubleshooting or quick iterations.
-The component that writes out object files (objwriter.dll/libobjwriter.so/libobjwriter.dylib) is based on LLVM and doesn't build in the runtime repo. It gets published as a NuGet package out of the [dotnet/llvm-project](https://github.com/dotnet/llvm-project) repo (branch [objwriter/12.x](https://github.com/dotnet/llvm-project/tree/objwriter/12.x)). If you're working on ObjWriter or bringing up a new platform that doesn't have ObjWriter packages yet, as additional pre-requisites you need to build objwriter out of that repo and replace the file in the output.
-
### Building packages
Run `build[.cmd|.sh] -c Release` from the repo root to build the NativeAOT toolchain packages. The build will place the toolchain packages at `artifacts\packages\Release\Shipping`. To publish your project using these packages:
diff --git a/docs/workflow/ci/failure-analysis.md b/docs/workflow/ci/failure-analysis.md
index 57917c841316..4b3e96334277 100644
--- a/docs/workflow/ci/failure-analysis.md
+++ b/docs/workflow/ci/failure-analysis.md
@@ -12,6 +12,19 @@
## Triaging errors seen in CI
+## Summary
+
+**Passing Build Analysis is required to merge into the runtime repo**.
+
+To resolve failures, do the following, in order:
+
+1. Fix the problem if your PR is the cause.
+2. For all failures not in the "Known test errors" section, [try to file a Known Build Error issue](#what-to-do-if-you-determine-the-failure-is-unrelated).
+3. If all else fails, perform a [manual bypass](#bypassing-build-analysis).
+
+
+## Details
+
In case of failure, any PR on the runtime will have a failed GitHub check - PR Build Analysis - which has a summary of all failures, including a list of matching known issues as well as any regressions introduced to the build or the tests. This tab should be your first stop for analyzing the PR failures.

@@ -78,6 +91,7 @@ If you have considered all the diagnostic artifacts and determined the failure i
````
It already contains most of the essential information, but *it is very important that you fill out the json blob*.
+ - You can now use the [Build Analysis Known Issue Helper](https://helix.dot.net/BuildAnalysis/CreateKnownIssues) to create an issue. It assists in adding the right set of labels, fill the necessary paths in the json blob, and it will validate that it matches the text presented for the issue found in the logs.
- You can add into the `ErrorMessage` field the string that you found uniquely identifies the issue. In case you need to use a regex, use the `ErrorPattern` field instead. This is a limited to a single-line, non-backtracking regex as described [here](https://github.com/dotnet/arcade/blob/main/Documentation/Projects/Build%20Analysis/KnownIssues.md#regex-matching). This regex also needs to be appropriately escaped. Check the [arcade known issues](https://github.com/dotnet/arcade/blob/main/Documentation/Projects/Build%20Analysis/KnownIssues.md#filling-out-known-issues-json-blob) documentation for a good guide on proper regex and JSON escaping.
- The field `ExcludeConsoleLog` describes if the execution logs should be considered on top of the individual test results. **For most cases, this should be set to `true` as the failure will happen within a single test**. Setting it to `false` will mean all failures within an xUnit set of tests will also get attributed to this particular error, since there's one log describing all the problems. Due to limitations in Known Issues around rate limiting and xUnit resiliency, setting `ExcludeConsoleLog=false` is necessary in two scenarios:
+ Nested tests as reported to Azure DevOps. Essentially this means theory failures, which look like this when reported in Azure DevOps: .
@@ -85,7 +99,11 @@ If you have considered all the diagnostic artifacts and determined the failure i
+ Native crashes in libraries also require using the console log. This is needed as the crash corrupts the test results to be reported to Azure DevOps, so only the console logs are left.
- Optionally you can add specifics as needed like leg, configuration parameters, available dump links.
-Once the issue is open, feel free to rerun the `Build Analysis` check and the issue should be recognized as known if all was filed correctly and you are ready to merge once all unrelated issues are marked as known. However, there are some known limitations to the system as previously described. Additionally, the system only looks at the error message the stacktrace fields of an Azure DevOps test result, and the console log in the helix queue. If rerunning the check doesn't pick up the known issue and you feel it should, feel free to tag @dotnet/runtime-infrastructure to request infrastructure team for help.
+Once the issue is open, feel free to rerun the `Build Analysis` check and the issue should be recognized as known if all was filed correctly and you are ready to merge once all unrelated issues are marked as known. However, there are some known limitations to the system as previously described. Additionally, the system only looks at the error message the stacktrace fields of an Azure DevOps test result, and the console log in the helix queue.
+
+The `Build Analysis` requests are sent to a queue. In certain scenarios, this queue can have many items to process and it can take a while for the status to be updated. If you do not see the status getting updated, be patient and wait at least 10 minutes before investigating further.
+
+If rerunning the check doesn't pick up the known issue and you feel it should, feel free to tag @dotnet/runtime-infrastructure to request infrastructure team for help.
After you do this, if the failure is occurring frequently as per the data captured in the recently opened issue, please disable the failing test(s) with the corresponding tracking issue link in a follow-up Pull Request.
@@ -95,6 +113,18 @@ After you do this, if the failure is occurring frequently as per the data captur
There are plenty of intermittent failures that won't manifest again on a retry. Therefore these steps should be followed for every iteration of the PR build, e.g. before retrying/rebuilding.
+### Bypassing build analysis
+
+To unconditionally bypass the build analysis check (turn it green), you can add a comment to your PR with the following text:
+
+```
+/ba-g
+```
+
+The `Build Analysis` requests are sent to a queue. In certain scenarios, this queue can have many items to process and it can take a while for the status to be updated. If you do not see the status getting updated, be patient and wait at least 10 minutes before investigating further.
+
+For more information, see https://github.com/dotnet/arcade/blob/main/Documentation/Projects/Build%20Analysis/EscapeMechanismforBuildAnalysis.md
+
### Examples of Build Analysis
#### Good usage examples
diff --git a/docs/workflow/ci/pr-guide.md b/docs/workflow/ci/pr-guide.md
index b2698ba5e489..e48dfe0fb7f1 100644
--- a/docs/workflow/ci/pr-guide.md
+++ b/docs/workflow/ci/pr-guide.md
@@ -15,7 +15,7 @@ To merge pull requests, you must have write permissions in the repository. If yo
## Pull Request Ownership
-Every pull request will have automatically a single `area-*` label assigned. The label not only indicates the code segment which the change touches but also the owner. We maintain a list of [areas owners](area-owners.md) for all dotnet/runtime labels. They are responsible for landing pull requests in their area in a timely manner and for helping contributors with their submitted pull request. You can ask them for assistance if you need help with landing your changes.
+Every pull request will have automatically a single `area-*` label assigned. The label not only indicates the code segment which the change touches but also the owner. We maintain a list of [areas owners](../../area-owners.md) for all dotnet/runtime labels. They are responsible for landing pull requests in their area in a timely manner and for helping contributors with their submitted pull request. You can ask them for assistance if you need help with landing your changes.
If during the code review process a merge conflict occurs the area owner is responsible for its resolution. Pull requests should not be on hold due to the author's unwillingness to resolve code conflicts. GitHub makes this easier by allowing simple conflict resolution using the [conflict-editor](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github).
diff --git a/docs/workflow/ci/triaging-failures.md b/docs/workflow/ci/triaging-failures.md
index 1baa56052774..bf5e80f7522e 100644
--- a/docs/workflow/ci/triaging-failures.md
+++ b/docs/workflow/ci/triaging-failures.md
@@ -8,7 +8,7 @@ stress mode test configuration failures, such as failures in a JIT stress test r
One goal of failure investigation is to quickly route failures to the correct area owner. The ownership of various product areas
is detailed [here](../../area-owners.md). The GitHub auto-tagging bot uses the ownership information
-in the file [fabricbot.json](../../../.github/fabricbot.json).
+in the file [Policy Service configuration](../../../.github/policies).
## Platform configuration
diff --git a/docs/workflow/debugging/coreclr/debugging-aot-compilers.md b/docs/workflow/debugging/coreclr/debugging-aot-compilers.md
index 341e5489548e..7896e1b8bb50 100644
--- a/docs/workflow/debugging/coreclr/debugging-aot-compilers.md
+++ b/docs/workflow/debugging/coreclr/debugging-aot-compilers.md
@@ -85,7 +85,7 @@ The object files generated by the ILC compiler contain debug information for met
The ILC compiler typically compiles the whole program - it loosely corresponds to the composite mode of crossgen2. There is a multifile mode, where each managed assembly corresponds to a single object file, but this mode is not shipping.
-The object files generated by the ILC compiler are written out using an LLVM-based object writer (consumed as a NuGet package built out of the dotnet/llvm-project repo, branch objwriter/12.x). The object writer uses the LLVM assembler APIs (APIs meant to be used by tools that convert textual assembly into machine code) to emit object files in PE/ELF/Mach-O formats.
+The supported object files generated by the ILC compiler are PE/ELF/Mach-O formats.
## Example of debugging a test application in Crossgen2
diff --git a/docs/workflow/debugging/coreclr/debugging-runtime.md b/docs/workflow/debugging/coreclr/debugging-runtime.md
index dd92fe93cfaf..6edce3c7646e 100644
--- a/docs/workflow/debugging/coreclr/debugging-runtime.md
+++ b/docs/workflow/debugging/coreclr/debugging-runtime.md
@@ -150,7 +150,7 @@ It might also be the case that you would need the latest changes in SOS, or you'
**NOTE**: Only `lldb` is supported to use with SOS. You can also use `gdb`, `cgdb`, or other debuggers, but you might not have access to SOS.
1. Perform a build of the _clr_ subset of the runtime repo.
-2. Start lldb passing `corerun`, the app to run (e.g. `HelloWorld.dll`), and any arguments this app might need: `lldb /path/to/corerun /path/to/app.dll `
+2. Start lldb passing `corerun`, the app to run (e.g. `HelloWorld.dll`), and any arguments this app might need: `lldb -- /path/to/corerun /path/to/app.dll `
3. If you're using the installed version of SOS, you can skip this step. If you built SOS manually, you have to load it before starting the debugging session: `plugin load /path/to/built/sos/libsosplugin.so`. Note that `.so` is for Linux, and `.dylib` is for macOS. You can find more information in the diagnostics repo [private sos build doc](https://github.com/dotnet/diagnostics/blob/main/documentation/using-sos-private-build.md).
4. Launch program: `process launch -s`
5. To stop breaks on _SIGUSR1_ signals used by the runtime run the following command: `process handle -s false SIGUSR1`
diff --git a/docs/workflow/debugging/mono/android-debugging.md b/docs/workflow/debugging/mono/android-debugging.md
index 918ac1503efa..7e86eb775324 100644
--- a/docs/workflow/debugging/mono/android-debugging.md
+++ b/docs/workflow/debugging/mono/android-debugging.md
@@ -57,25 +57,27 @@ Since you're debugging an optimized release build, it is likely the debugger wil
## Native debugging using a local debug build of Mono
-Build the runtime for your android architecture: `ANDROID_NDK_ROOT= ./build.sh --os android --arch x86 -c Debug`. See the instructions for [Testing Android](../../testing/libraries/testing-android.md) for details.
+Ensure the prerequisites are met for [Testing Android](../../testing/libraries/testing-android.md#prerequisites).
+Build the runtime for your android architecture `` and keep debug symbols in the binary:
-In the source code for the C# project, add the following to the .csproj (replacing `` by the appropriate location):
+`./build.sh -s mono+libs -os android -arch -c Debug /p:KeepNativeSymbols=true`
+
+In the source code for the C# project, add the following to the .csproj (replacing `` by the appropriate location and `` with the built android architecture):
```
-
```
-Then rebuild and reinstall the project, open the apk in Android Studio, and debug. The
-runtime native libraries will be stripped, so to make use of debug symbols, you
-will need to follow the steps above (rename `*.so.dbg` in the artifacts to
-`*.so.so` and add them to the APK project in Android Studio)
+Then rebuild and reinstall the project, open the apk in Android Studio (File > Profile or Debug APK), and debug.
+
+Note: If debugging in Android Studio stops at signals `SIGPWR` and `SIGXCPU` during startup, configure LLDB to not stop the process for those signals via `process handle -p true -s false -n true SIGPWR` and `process handle -p true -s false -n true SIGXCPU` in Android Studio's LLDB tab.
## Native and managed debugging or debugging the managed debugger
diff --git a/docs/workflow/debugging/mono/wasm-debugging.md b/docs/workflow/debugging/mono/wasm-debugging.md
index 59014ef147e2..80b06319eb36 100644
--- a/docs/workflow/debugging/mono/wasm-debugging.md
+++ b/docs/workflow/debugging/mono/wasm-debugging.md
@@ -180,8 +180,8 @@ $func166 @ dotnet.wasm:0xba0a
$func2810 @ dotnet.wasm:0xabacf
$func1615 @ dotnet.wasm:0x6f8eb
$func1619 @ dotnet.wasm:0x6ff58
-$mono_wasm_invoke_method @ dotnet.wasm:0x96c9
-Module._mono_wasm_invoke_method @ dotnet.6.0.1.hopd7ipo8x.js:1
+$mono_wasm_invoke_jsexport @ dotnet.wasm:0x96c9
+Module.mono_wasm_invoke_jsexport @ dotnet.6.0.1.hopd7ipo8x.js:1
managed__Microsoft_AspNetCore_Components_WebAssembly__Microsoft_AspNetCore_Components_WebAssembly_Services_DefaultWebAssemblyJSRuntime_BeginInvokeDotNet @ managed__Microsoft_AspNetCore_Components_WebAssembly__Microsoft_AspNetCore_Components_WebAssembly_Services_DefaultWebAssemblyJSRuntime_BeginInvokeDotNet:19
beginInvokeDotNetFromJS @ blazor.webassembly.js:1
b @ blazor.webassembly.js:1
@@ -244,8 +244,8 @@ $mono_jit_runtime_invoke @ dotnet.wasm:0x1dec32
$do_runtime_invoke @ dotnet.wasm:0x95fca
$mono_runtime_try_invoke @ dotnet.wasm:0x966fe
$mono_runtime_invoke @ dotnet.wasm:0x98982
-$mono_wasm_invoke_method @ dotnet.wasm:0x227de2
-Module._mono_wasm_invoke_method @ dotnet..y6ggkhlo8e.js:9927
+$mono_wasm_invoke_jsexport @ dotnet.wasm:0x227de2
+Module.mono_wasm_invoke_jsexport @ dotnet..y6ggkhlo8e.js:9927
managed__Microsoft_AspNetCore_Components_WebAssembly__Microsoft_AspNetCore_Components_WebAssembly_Services_DefaultWebAssemblyJSRuntime_BeginInvokeDotNet @ managed__Microsoft_AspNetCore_Components_WebAssembly__Microsoft_AspNetCore_Components_WebAssembly_Services_DefaultWebAssemblyJSRuntime_BeginInvokeDotNet:19
beginInvokeDotNetFromJS @ blazor.webassembly.js:1
b @ blazor.webassembly.js:1
diff --git a/docs/workflow/testing/host/testing.md b/docs/workflow/testing/host/testing.md
index 35c7359c411a..a217d1dd0ab9 100644
--- a/docs/workflow/testing/host/testing.md
+++ b/docs/workflow/testing/host/testing.md
@@ -13,15 +13,15 @@ To build the host tests, first build the product:
* [CoreCLR](../../building/coreclr/README.md) build instructions
* [Libraries](../../building/libraries/README.md) build instructions
-2. Build the host and packs:
+2. Build the host:
```
- build.cmd/sh -subset host+packs.product -runtimeConfiguration Release -librariesConfiguration Release
+ build.cmd/sh -subset host -runtimeConfiguration Release -librariesConfiguration Release
```
If using a configuration other than Release for CoreCLR/libraries, specify the desired configuration in the `-runtimeConfiguration`/`-librariesConfiguration` arguments.
### Building all tests
-The host tests are part of the `host` subset by default, so building the `host` subset also builds the host test. To build just the host tests:
+The host tests are part of the `host` subset by default, so building the `host` subset also builds the host tests. To build just the host tests:
```
build.cmd/sh -subset host.tests -runtimeConfiguration Release -librariesConfiguration Release
```
@@ -36,16 +36,18 @@ dotnet build src\installer\tests\HostActivation.Tests
## Test context
The host tests depend on:
- 1. Product binaries in a directory layout matching that of a .NET install
- 2. Restored [test projects](/src/installer/tests/Assets/TestProjects) which will be built and run by the tests
- 3. TestContextVariables.txt file with property and value pairs which will be read by the tests
+ 1. Pre-built [test project](/src/installer/tests/Assets/Projects) output which will be copied and run by the tests. The `host.pretest` subset builds these projects.
+ 2. Product binaries in a directory layout matching that of a .NET install. The `host.pretest` subset creates this layout.
+ 3. TestContextVariables.txt files with property and value pairs which will be read by the tests. The `host.tests` subset creates these files as part of building the tests.
When [running all tests](#running-all-tests), the build is configured such that these are created/performed before the start of the test run.
-In order to create (or update) these dependencies without running all tests, the build targets that create them - RefreshProjectTestAssets and SetupTestContextVariables - can be directly run for the desired test project. For example:
-```
-dotnet build src\installer\tests\HostActivation.Tests -t:RefreshProjectTestAssets;SetupTestContextVariables -p:RuntimeConfiguration=Release -p:LibrariesConfiguration=Release
-```
+In order to create (or update) these dependencies without running all tests:
+ 1. Build the `host.pretest` subset. By default, this is included in the `host` subset. This corresponds to (1) and (2) above.
+ 2. Build the desired test project. This corresponds to (3) above. Building the test itself will run the `SetupTestContextVariables` target, but it can also be run independently - for example:
+ ```
+ dotnet build src\installer\tests\HostActivation.Tests -t:SetupTestContextVariables -p:RuntimeConfiguration=Release -p:LibrariesConfiguration=Release
+ ```
## Running tests
@@ -78,6 +80,21 @@ The `category!=failing` is to respect the [filtering traits](../libraries/filter
The [Microsoft.DotNet.CoreSetup.sln](/src/installer/Microsoft.DotNet.CoreSetup.sln) can be used to run and debug host tests through Visual Studio. When using the solution, the product should have already been [built](#building-tests) and the [test context](#test-context) set up.
+If you built the runtime or libraries with a different configuration from the host, you have to specify this when starting visual studio:
+
+```console
+build.cmd -vs Microsoft.DotNet.CoreSetup -rc Release -lc Release
+```
+
+## Investigating failures
+
+When [running all tests](#running-all-tests), reports with results will be generated under `\artifacts\TestResults`. When [running individual tests](#running-specific-tests), results will be output to the console by default and can be configured via [`dotnet test` options](https://learn.microsoft.com/dotnet/core/tools/dotnet-test#options).
+
+In order to test the hosting components, the tests launch a separate process (e.g. `dotnet`, apphost, native host) and validate the expected output (standard output and error) of the launched process. This usually involves copying or creating test artifacts in the form of an application to run or a .NET install to run against.
+
+On failure, tests will report the file, arguments, and environment for the launched process that failed validation. With [preserved test artifacts](#preserving-test-artifacts), this information can be used to directly debug the specific scenario that the test was running.
+
### Preserving test artifacts
-In order to test the hosting components, the tests launch a separate process (e.g. `dotnet`, apphost, native host) and validate the expected output (standard output and error) of the launched process. This usually involves copying or creating test artifacts in the form of an application to run or a .NET install to run against. The tests will delete these artifacts after the test finishes. To allow inspection or usage after the test finishes, set the environment variable `PRESERVE_TEST_RUNS=1` to avoid deleting the test artifacts.
+The tests will delete any generated test artifacts after the test finishes. To allow inspection or usage after the test finishes, set the environment variable `PRESERVE_TEST_RUNS=1` to avoid deleting the test artifacts.
+
diff --git a/docs/workflow/testing/host/using-apphost.md b/docs/workflow/testing/host/using-apphost.md
index 67c129ce338f..764dc6ad68e5 100644
--- a/docs/workflow/testing/host/using-apphost.md
+++ b/docs/workflow/testing/host/using-apphost.md
@@ -23,8 +23,8 @@ Building and publishing your project should now use the `apphost`/`singlefilehos
Alternatives to this method include copying the desired apphost to the appropriate `/packs` and NuGet cache directories or building the NuGet packages locally and configuring the application to use them via a NuGet.config and the `KnownAppHostPack` item.
-## Pointing at a local .NET root
+# Pointing at a local .NET root
For a [framework-dependent application](https://docs.microsoft.com/dotnet/core/deploying/#publish-framework-dependent), you can set the `DOTNET_ROOT` environment variable to point at a local .NET layout.
-The [libraries tests](../libraries/testing.md) construct and use such a layout based on your local runtime and libraries build as part of the `libs.pretest` subset. To use that layout, set `DOTNET_ROOT=/artifacts/bin/testhost/net8.0---`. Note that the host components (`hostfxr`, `hostpolicy`) in that layout are not from the local build.
+The [libraries tests](../libraries/testing.md) construct and use such a layout based on your local runtime, host, and libraries build as part of the `libs.pretest` subset. To use that layout, set `DOTNET_ROOT=/artifacts/bin/testhost/net8.0---` and then run the .NET application.
diff --git a/eng/Analyzers.targets b/eng/Analyzers.targets
index 7cb7a76abac7..856ceb89ae9c 100644
--- a/eng/Analyzers.targets
+++ b/eng/Analyzers.targets
@@ -8,7 +8,7 @@
- false
+ false
$(RunAnalyzers)
diff --git a/eng/CodeAnalysis.src.globalconfig b/eng/CodeAnalysis.src.globalconfig
index 2677ac469e66..21a53462cc5d 100644
--- a/eng/CodeAnalysis.src.globalconfig
+++ b/eng/CodeAnalysis.src.globalconfig
@@ -274,6 +274,12 @@ dotnet_diagnostic.CA1512.severity = warning
# CA1513: Use ObjectDisposedException throw helper
dotnet_diagnostic.CA1513.severity = warning
+# CA1514: Avoid redundant length argument
+dotnet_diagnostic.CA1514.severity = warning
+
+# CA1515: Consider making public types internal
+dotnet_diagnostic.CA1515.severity = none
+
# CA1700: Do not name enum values 'Reserved'
dotnet_diagnostic.CA1700.severity = none
@@ -483,6 +489,15 @@ dotnet_diagnostic.CA1863.severity = suggestion
# CA1864: Prefer the 'IDictionary.TryAdd(TKey, TValue)' method
dotnet_diagnostic.CA1864.severity = warning
+# CA1865: Use char overload
+dotnet_diagnostic.CA1865.severity = warning
+
+# CA1866: Use char overload
+dotnet_diagnostic.CA1866.severity = warning
+
+# CA1867: Use char overload
+dotnet_diagnostic.CA1867.severity = warning
+
# CA1868: Unnecessary call to 'Contains' for sets
dotnet_diagnostic.CA1868.severity = warning
@@ -492,6 +507,12 @@ dotnet_diagnostic.CA1869.severity = warning
# CA1870: Use a cached 'SearchValues' instance
dotnet_diagnostic.CA1870.severity = warning
+# CA1871: Do not pass a nullable struct to 'ArgumentNullException.ThrowIfNull'
+dotnet_diagnostic.CA1871.severity = warning
+
+# CA1872: Prefer 'Convert.ToHexString' and 'Convert.ToHexStringLower' over call chains based on 'BitConverter.ToString'
+dotnet_diagnostic.CA1872.severity = warning
+
# CA2000: Dispose objects before losing scope
dotnet_diagnostic.CA2000.severity = none
@@ -540,6 +561,9 @@ dotnet_diagnostic.CA2020.severity = warning
# CA2021: Do not call Enumerable.Cast or Enumerable.OfType with incompatible types
dotnet_diagnostic.CA2021.severity = warning
+# CA2022: Avoid inexact read with 'Stream.Read'
+dotnet_diagnostic.CA2022.severity = warning
+
# CA2100: Review SQL queries for security vulnerabilities
dotnet_diagnostic.CA2100.severity = none
@@ -601,9 +625,6 @@ dotnet_diagnostic.CA2226.severity = none
# CA2227: Collection properties should be read only
dotnet_diagnostic.CA2227.severity = none
-# CA2229: Implement serialization constructors
-dotnet_diagnostic.CA2229.severity = warning
-
# CA2231: Overload operator equals on overriding value type Equals
dotnet_diagnostic.CA2231.severity = none
@@ -679,6 +700,18 @@ dotnet_diagnostic.CA2260.severity = warning
# CA2261: Do not use ConfigureAwaitOptions.SuppressThrowing with Task
dotnet_diagnostic.CA2261.severity = warning
+# CA2262: Set 'MaxResponseHeadersLength' properly
+dotnet_diagnostic.CA2262.severity = warning
+
+# CA2263: Prefer generic overload when type is known
+dotnet_diagnostic.CA2263.severity = suggestion
+
+# CA2264: Do not pass a non-nullable value to 'ArgumentNullException.ThrowIfNull'
+dotnet_diagnostic.CA2264.severity = warning
+
+# CA2265: Do not compare Span to 'null' or 'default'
+dotnet_diagnostic.CA2265.severity = warning
+
# CA2300: Do not use insecure deserializer BinaryFormatter
dotnet_diagnostic.CA2300.severity = none
@@ -1806,7 +1839,7 @@ dotnet_diagnostic.IDE0200.severity = warning
# IDE0210: Use top-level statements
dotnet_diagnostic.IDE0210.severity = none
-# IDE0211: Use program main
+# IDE0211: Convert to 'Program.Main' style program
dotnet_diagnostic.IDE0211.severity = none
# IDE0220: foreach cast
@@ -1824,6 +1857,9 @@ dotnet_diagnostic.IDE0241.severity = suggestion
# IDE0250: Make struct readonly
dotnet_diagnostic.IDE0250.severity = suggestion
+# IDE0251: Make member readonly
+dotnet_diagnostic.IDE0251.severity = suggestion
+
# IDE0260: Use pattern matching
dotnet_diagnostic.IDE0260.severity = suggestion
@@ -1833,6 +1869,27 @@ dotnet_diagnostic.IDE0270.severity = suggestion
# IDE0280: Use 'nameof'
dotnet_diagnostic.IDE0280.severity = warning
+# IDE0290: Use primary constructor
+dotnet_diagnostic.IDE0290.severity = suggestion
+
+# IDE0300: Use collection expression for array
+dotnet_diagnostic.IDE0300.severity = suggestion
+
+# IDE0301: Use collection expression for empty
+dotnet_diagnostic.IDE0301.severity = suggestion
+
+# IDE0302: Use collection expression for stackalloc
+dotnet_diagnostic.IDE0302.severity = suggestion
+
+# IDE0303: Use collection expression for Create()
+dotnet_diagnostic.IDE0303.severity = suggestion
+
+# IDE0304: Use collection expression for builder
+dotnet_diagnostic.IDE0304.severity = suggestion
+
+# IDE0305: Use collection expression for fluent
+dotnet_diagnostic.IDE0305.severity = suggestion
+
# IDE1005: Delegate invocation can be simplified.
dotnet_diagnostic.IDE1005.severity = warning
@@ -1853,3 +1910,9 @@ dotnet_diagnostic.IDE2003.severity = silent
# IDE2004: Blank line not allowed after constructor initializer colon
dotnet_diagnostic.IDE2004.severity = silent
+
+# IDE2005: Blank line not allowed after conditional expression token
+dotnet_diagnostic.IDE2005.severity = silent
+
+# IDE2006: Blank line not allowed after arrow expression clause token
+dotnet_diagnostic.IDE2006.severity = silent
diff --git a/eng/CodeAnalysis.test.globalconfig b/eng/CodeAnalysis.test.globalconfig
index 79e35931782f..0d944fbd890f 100644
--- a/eng/CodeAnalysis.test.globalconfig
+++ b/eng/CodeAnalysis.test.globalconfig
@@ -273,6 +273,12 @@ dotnet_diagnostic.CA1512.severity = none
# CA1513: Use ObjectDisposedException throw helper
dotnet_diagnostic.CA1513.severity = none
+# CA1514: Avoid redundant length argument
+dotnet_diagnostic.CA1514.severity = none
+
+# CA1515: Consider making public types internal
+dotnet_diagnostic.CA1515.severity = none
+
# CA1700: Do not name enum values 'Reserved'
dotnet_diagnostic.CA1700.severity = none
@@ -480,6 +486,15 @@ dotnet_diagnostic.CA1863.severity = none
# CA1864: Prefer the 'IDictionary.TryAdd(TKey, TValue)' method
dotnet_diagnostic.CA1864.severity = none
+# CA1865: Use char overload
+dotnet_diagnostic.CA1865.severity = none
+
+# CA1866: Use char overload
+dotnet_diagnostic.CA1866.severity = none
+
+# CA1867: Use char overload
+dotnet_diagnostic.CA1867.severity = none
+
# CA1868: Unnecessary call to 'Contains' for sets
dotnet_diagnostic.CA1868.severity = none
@@ -489,6 +504,12 @@ dotnet_diagnostic.CA1869.severity = none
# CA1870: Use a cached 'SearchValues' instance
dotnet_diagnostic.CA1870.severity = none
+# CA1871: Do not pass a nullable struct to 'ArgumentNullException.ThrowIfNull'
+dotnet_diagnostic.CA1871.severity = none
+
+# CA1872: Prefer 'Convert.ToHexString' and 'Convert.ToHexStringLower' over call chains based on 'BitConverter.ToString'
+dotnet_diagnostic.CA1872.severity = none
+
# CA2000: Dispose objects before losing scope
dotnet_diagnostic.CA2000.severity = none
@@ -537,6 +558,9 @@ dotnet_diagnostic.CA2020.severity = none
# CA2021: Do not call Enumerable.Cast or Enumerable.OfType with incompatible types
dotnet_diagnostic.CA2021.severity = none
+# CA2022: Avoid inexact read with 'Stream.Read'
+dotnet_diagnostic.CA2022.severity = none
+
# CA2100: Review SQL queries for security vulnerabilities
dotnet_diagnostic.CA2100.severity = none
@@ -675,6 +699,18 @@ dotnet_diagnostic.CA2260.severity = none
# CA2261: Do not use ConfigureAwaitOptions.SuppressThrowing with Task
dotnet_diagnostic.CA2261.severity = none
+# CA2262: Set 'MaxResponseHeadersLength' properly
+dotnet_diagnostic.CA2262.severity = none
+
+# CA2263: Prefer generic overload when type is known
+dotnet_diagnostic.CA2263.severity = none
+
+# CA2264: Do not pass a non-nullable value to 'ArgumentNullException.ThrowIfNull'
+dotnet_diagnostic.CA2264.severity = none
+
+# CA2265: Do not compare Span to 'null' or 'default'
+dotnet_diagnostic.CA2265.severity = none
+
# CA2300: Do not use insecure deserializer BinaryFormatter
dotnet_diagnostic.CA2300.severity = none
@@ -1800,7 +1836,7 @@ dotnet_diagnostic.IDE0200.severity = silent
# IDE0210: Use top-level statements
dotnet_diagnostic.IDE0210.severity = silent
-# IDE0211: Use program main
+# IDE0211: Convert to 'Program.Main' style program
dotnet_diagnostic.IDE0211.severity = silent
# IDE0220: foreach cast
@@ -1818,6 +1854,9 @@ dotnet_diagnostic.IDE0241.severity = silent
# IDE0250: Make struct readonly
dotnet_diagnostic.IDE0250.severity = silent
+# IDE0251: Make member readonly
+dotnet_diagnostic.IDE0251.severity = silent
+
# IDE0260: Use pattern matching
dotnet_diagnostic.IDE0260.severity = silent
@@ -1827,6 +1866,27 @@ dotnet_diagnostic.IDE0270.severity = silent
# IDE0280: Use 'nameof'
dotnet_diagnostic.IDE0280.severity = silent
+# IDE0290: Use primary constructor
+dotnet_diagnostic.IDE0290.severity = silent
+
+# IDE0300: Use collection expression for array
+dotnet_diagnostic.IDE0300.severity = silent
+
+# IDE0301: Use collection expression for empty
+dotnet_diagnostic.IDE0301.severity = silent
+
+# IDE0302: Use collection expression for stackalloc
+dotnet_diagnostic.IDE0302.severity = silent
+
+# IDE0303: Use collection expression for Create()
+dotnet_diagnostic.IDE0303.severity = silent
+
+# IDE0304: Use collection expression for builder
+dotnet_diagnostic.IDE0304.severity = silent
+
+# IDE0305: Use collection expression for fluent
+dotnet_diagnostic.IDE0305.severity = silent
+
# IDE1005: Delegate invocation can be simplified.
dotnet_diagnostic.IDE1005.severity = silent
@@ -1848,6 +1908,12 @@ dotnet_diagnostic.IDE2003.severity = silent
# IDE2004: Blank line not allowed after constructor initializer colon
dotnet_diagnostic.IDE2004.severity = silent
+# IDE2005: Blank line not allowed after conditional expression token
+dotnet_diagnostic.IDE2005.severity = silent
+
+# IDE2006: Blank line not allowed after arrow expression clause token
+dotnet_diagnostic.IDE2006.severity = silent
+
# xUnit1000: Test classes must be public
dotnet_diagnostic.xUnit1000.severity = warning
diff --git a/eng/DiaSymReaderNative.targets b/eng/DiaSymReaderNative.targets
index caa482f4b6e8..ac8dc7e36a06 100644
--- a/eng/DiaSymReaderNative.targets
+++ b/eng/DiaSymReaderNative.targets
@@ -18,7 +18,7 @@
package can't be referenced directly but rather has to have it's assets manually copied
out. This logic is responsible for doing that.
-->
-
+
PreserveNewest
false
diff --git a/eng/DotNetBuild.props b/eng/DotNetBuild.props
index c830b112c32c..06ea2ee04665 100644
--- a/eng/DotNetBuild.props
+++ b/eng/DotNetBuild.props
@@ -32,17 +32,22 @@
true
true
true
+ true
-
+
+
+
+ $(InnerBuildArgs) $(FlagParameterPrefix)restore $(FlagParameterPrefix)build $(FlagParameterPrefix)publish
+
$(InnerBuildArgs) $(FlagParameterPrefix)arch $(TargetArch)
- $(InnerBuildArgs) $(FlagParameterPrefix)os $(TargetOS)
- $(InnerBuildArgs) $(FlagParameterPrefix)cross
+ $(InnerBuildArgs) $(FlagParameterPrefix)os $(TargetOS)
+ $(InnerBuildArgs) $(FlagParameterPrefix)cross
$(InnerBuildArgs) $(FlagParameterPrefix)configuration $(Configuration)
$(InnerBuildArgs) $(FlagParameterPrefix)allconfigurations
$(InnerBuildArgs) $(FlagParameterPrefix)verbosity $(LogVerbosity)
@@ -57,14 +62,25 @@
$(InnerBuildArgs) /p:AdditionalRuntimeIdentifierParent=$(BaseOS)
+
+ $(InnerBuildArgs) /p:WasmEnableThreads=true
+ $(InnerBuildArgs) $(FlagParameterPrefix)s clr.nativeaotlibs+clr.nativeaotruntime+libs+packs /p:BuildNativeAOTRuntimePack=true /p:SkipLibrariesNativeRuntimePackages=true
+ $(InnerBuildArgs) $(FlagParameterPrefix)pgoinstrument
- $(InnerBuildArgs) /p:ArcadeBuildFromSource=true
- $(InnerBuildArgs) /p:ArcadeBuildVertical=true
+ $(InnerBuildArgs) /p:DotNetBuildRepo=true
+ $(InnerBuildArgs) /p:DotNetBuildOrchestrator=true
$(InnerBuildArgs) /p:OfficialBuildId=$(OfficialBuildId)
$(InnerBuildArgs) /p:ContinuousIntegrationBuild=$(ContinuousIntegrationBuild)
$(InnerBuildArgs) /p:PortableBuild=$(PortableBuild)
$(InnerBuildArgs) /p:RestoreConfigFile=$(RestoreConfigFile)
+
+
+ $(InnerBuildArgs) /p:SourceBuiltAssetsDir=$(SourceBuiltAssetsDir)
+ $(InnerBuildArgs) /p:SourceBuiltShippingPackagesDir=$(SourceBuiltShippingPackagesDir)
+ $(InnerBuildArgs) /p:SourceBuiltNonShippingPackagesDir=$(SourceBuiltNonShippingPackagesDir)
+ $(InnerBuildArgs) /p:SourceBuiltAssetManifestsDir=$(SourceBuiltAssetManifestsDir)
+ $(InnerBuildArgs) /p:SourceBuiltSymbolsDir=$(SourceBuiltSymbolsDir)
diff --git a/eng/Publishing.props b/eng/Publishing.props
index 920e79cbbd2f..1507fc850339 100644
--- a/eng/Publishing.props
+++ b/eng/Publishing.props
@@ -1,6 +1,39 @@
-
+
- 3
+ true
-
\ No newline at end of file
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/eng/Subsets.props b/eng/Subsets.props
index 4a0277852d17..8026bf97e046 100644
--- a/eng/Subsets.props
+++ b/eng/Subsets.props
@@ -40,7 +40,12 @@
mono+libs+packs
mono+libs+host+packs
- clr+libs+tools+host+packs
+ clr+libs+tools+host+packs
+
+
+
+
+ true
@@ -81,19 +86,19 @@
'$(BuildTargetFramework)' == '' or
'$(BuildAllConfigurations)' == 'true'">libs.native+
$(DefaultLibrariesSubsets)libs.sfx+libs.oob+libs.pretest
-
+
$(DefaultLibrariesSubsets)+libs.tests
tools.illink
host.native+host.tools+host.pkg
- $(DefaultHostSubsets)+host.pretest+host.tests
+ $(DefaultHostSubsets)+host.pretest+host.tests
host.native
packs.product
- $(DefaultPacksSubsets)+packs.tests
- $(DefaultPacksSubsets)+packs.installers
+ $(DefaultPacksSubsets)+packs.tests
+ $(DefaultPacksSubsets)+packs.installers
$(DefaultPacksSubsets)+mono.manifests
@@ -116,10 +121,12 @@
- true
+ <_NativeAotSupportedOS Condition="'$(TargetOS)' == 'windows' or '$(TargetOS)' == 'linux' or '$(TargetOS)' == 'osx' or '$(TargetOS)' == 'maccatalyst' or '$(TargetOS)' == 'iossimulator' or '$(TargetOS)' == 'ios' or '$(TargetOS)' == 'tvossimulator' or '$(TargetOS)' == 'tvos' or '$(TargetOS)' == 'freebsd'">true
+ <_NativeAotSupportedArch Condition="'$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64' or '$(TargetArchitecture)' == 'arm' or ('$(TargetOS)' == 'windows' and '$(TargetArchitecture)' == 'x86')">true
+ true
- true
+ true
@@ -261,7 +268,7 @@
-
+
@@ -352,7 +359,7 @@
$(CoreClrProjectRoot)tools\aot\ILCompiler\repro\repro.csproj;
$(CoreClrProjectRoot)tools\r2rtest\R2RTest.csproj;
$(CoreClrProjectRoot)tools\PdbChecker\PdbChecker.csproj;
- $(CoreClrProjectRoot)tools\AssemblyChecker\AssemblyChecker.csproj" Category="clr" Condition="'$(DotNetBuildFromSource)' != 'true'"/>
+ $(CoreClrProjectRoot)tools\AssemblyChecker\AssemblyChecker.csproj" Category="clr" Condition="'$(DotNetBuildSourceOnly)' != 'true'"/>
@@ -366,11 +373,11 @@
+ Test="true" Category="clr" Condition="'$(DotNetBuildSourceOnly)' != 'true'"/>
+ Test="true" Category="clr" Condition="'$(DotNetBuildSourceOnly)' != 'true' and '$(NativeAotSupported)' == 'true'"/>
+ Test="true" Category="clr" Condition="'$(DotNetBuildSourceOnly)' != 'true' and '$(NativeAotSupported)' == 'true'"/>
@@ -402,9 +409,9 @@
-
+
-
+
@@ -464,7 +471,7 @@
-
+
@@ -509,7 +516,7 @@
-
+
@@ -524,10 +531,10 @@
-
+
-
+
@@ -537,7 +544,7 @@
-
+
@@ -547,12 +554,12 @@
-
+
-
+
diff --git a/eng/Tools.props b/eng/Tools.props
index 01cae1f2b230..3baa40f4f32e 100644
--- a/eng/Tools.props
+++ b/eng/Tools.props
@@ -11,7 +11,7 @@
-
+
diff --git a/eng/Version.Details.xml b/eng/Version.Details.xml
index 98c699e1821b..b5717f05a5f5 100644
--- a/eng/Version.Details.xml
+++ b/eng/Version.Details.xml
@@ -1,84 +1,52 @@
-
+
https://github.com/dotnet/icu
- 694cd153a9083da273595fabb73818d4e8a49f40
+ 1441a3fcbfa87c94b98a27605b06db7dd862f3e4
-
+
https://github.com/dotnet/msquic
- 3fb2583170384341dbbc444cd5bb3d2319433fb6
+ 6281631a8328ffdbb1b63b231af1aaa803915b23
https://github.com/dotnet/wcf
7f504aabb1988e9a093c1e74d8040bd52feb2f01
-
+
https://github.com/dotnet/emsdk
- d3abc57b72e22d012e3601feea54b8e3dd64ff21
+ 9ad7c262f14dc5e40a64030ade7788b36e74adf0
-
+
https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
+ 8b4f10702e13ea221a33e91c2ef46c4b7910b56c
-
+
https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
+ 8b4f10702e13ea221a33e91c2ef46c4b7910b56c
-
+
https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
+ 8b4f10702e13ea221a33e91c2ef46c4b7910b56c
-
+
https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
+ 8b4f10702e13ea221a33e91c2ef46c4b7910b56c
-
+
https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
+ 8b4f10702e13ea221a33e91c2ef46c4b7910b56c
-
+
https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
+ 8b4f10702e13ea221a33e91c2ef46c4b7910b56c
-
+
https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
+ 8b4f10702e13ea221a33e91c2ef46c4b7910b56c
-
+
https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
-
-
- https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
-
-
- https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
-
-
- https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
-
-
- https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
-
-
- https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
-
-
- https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
-
-
- https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
-
-
- https://github.com/dotnet/llvm-project
- cb7d881de3674394a5f98d167bfb58f9aff9768b
+ 8b4f10702e13ea221a33e91c2ef46c4b7910b56c
https://github.com/dotnet/command-line-api
@@ -90,352 +58,351 @@
a045dd54a4c44723c215d992288160eb1401bb7f
-
+
https://github.com/dotnet/cecil
- b8c2293cd1cbd9d0fe6f32d7b5befbd526b5a175
+ 9c8ea966df62f764523b51772763e74e71040a92
-
+
https://github.com/dotnet/cecil
- b8c2293cd1cbd9d0fe6f32d7b5befbd526b5a175
+ 9c8ea966df62f764523b51772763e74e71040a92
-
+
https://github.com/dotnet/emsdk
- d3abc57b72e22d012e3601feea54b8e3dd64ff21
+ 9ad7c262f14dc5e40a64030ade7788b36e74adf0
-
+
https://github.com/dotnet/emsdk
- d3abc57b72e22d012e3601feea54b8e3dd64ff21
+ 9ad7c262f14dc5e40a64030ade7788b36e74adf0
-
+
https://github.com/dotnet/source-build-reference-packages
- 6b94d1513777c3aa0426f648649ce06d0d705bb2
+ c0b5d69a1a1513528c77fffff708c7502d57c35c
-
+
https://github.com/dotnet/source-build-externals
- f1ef074dfcf79d2f2da6e6ff9df8696a32aa063c
+ 1e2e91d2544726b2cf68109f946178ef6bef3ad9
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/arcade
- f7eb7794c703dc29a83b414b786e9a154f0ca042
+ 541820fbd313f9bb82b756b66d258fe316d5e48b
-
+
https://github.com/dotnet/runtime-assets
- a321e366dc8783b4b84127eb50d7feeda6702c0f
+ ad97a45c2567fa7c3a067079f166c3f3c9fecd60
-
+
https://github.com/dotnet/runtime-assets
- a321e366dc8783b4b84127eb50d7feeda6702c0f
+ ad97a45c2567fa7c3a067079f166c3f3c9fecd60
-
+
https://github.com/dotnet/runtime-assets
- a321e366dc8783b4b84127eb50d7feeda6702c0f
+ ad97a45c2567fa7c3a067079f166c3f3c9fecd60
-
+
https://github.com/dotnet/runtime-assets
- a321e366dc8783b4b84127eb50d7feeda6702c0f
+ ad97a45c2567fa7c3a067079f166c3f3c9fecd60
-
+
https://github.com/dotnet/runtime-assets
- a321e366dc8783b4b84127eb50d7feeda6702c0f
+ ad97a45c2567fa7c3a067079f166c3f3c9fecd60
-
+
https://github.com/dotnet/runtime-assets
- a321e366dc8783b4b84127eb50d7feeda6702c0f
+ ad97a45c2567fa7c3a067079f166c3f3c9fecd60
-
+
https://github.com/dotnet/runtime-assets
- a321e366dc8783b4b84127eb50d7feeda6702c0f
+ ad97a45c2567fa7c3a067079f166c3f3c9fecd60
-
+
https://github.com/dotnet/runtime-assets
- a321e366dc8783b4b84127eb50d7feeda6702c0f
+ ad97a45c2567fa7c3a067079f166c3f3c9fecd60
-
+