* Synthesize a valid ECMA-335 image for read/write metadata instead of providing a separate metadata reader
* Remove copies
* Add a comment
* Create EcmaMetadata contract for handling all metadata retrieval and remove metadata handling completely from the Loader contract.
* Add EcmaMetadata contract to CoreCLR's list of implemented contracts
---------
Co-authored-by: Elinor Fung <elfung@microsoft.com>
Add a number of new `MethodDesc` contract definitions
| Contract algorithm on RuntimeTypeSystem |
| --- |
| `IsGenericMethodDefinition`|
|`GetGenericMethodInstantiation`|
|`GetMethodToken`|
|`IsArrayMethod`|
|`IsDynamicMethod`|
|`IsStoredSigMethodDesc`|
|`IsNoMetadataMethod`|
|`IsILStub`|
Update cDAC compat asserts in cDAC to always be enabled by using a tls variable in `mscordaccore`
Implement `GetMethodDescName` on `ISOSDacInterface` in the `cdacreader`
Stub out an implementation of `GetPath` in the `Loader` contract used in a fallback after a fallback. This will need further work, but is included to make sure the code path isn't lost.
Fix the `EcmaMetadataReader` to be able to find blobs in the metadata
Add ability to read target data from a buffer held on the cdac side using the `Target` class. This was needed to handle signature containing a `CorElementType.Internal`.
And finally actually implement the name generation algorithm via a line for line port from the CoreCLR codebase.
Contributes to https://github.com/dotnet/runtime/issues/99302
1. Add the MethodDefToILCodeVersioningState lookup map, too.
2. In future work (for example the SOS GetMethodDescData method) we will need to perform lookups in some of these lookup maps, so we will want the offsets of their Count and Next fields, not just a pointer to the table data. Change the data descriptor to return the offsets of the LookupMap structs themselves, not their `pTable` member
3. Update SOSDacImpl.GetModuleData implementation to manually add the table data offset to the lookup map addresses that are used by that method.
- Add `SyncTableEntry`, `SyncBlock`, `InteropSyncBlockInfo` data descriptors, `SyncTableEntries` global
- Get the sync block corresponding to a given object address in `Object` contract
- Add `GetComData` to `Object` contract
- Finish implementation of `ISOSDacInterface::GetObjectData` such that it populates the RCW/CCW
- Add test helpers for mocking out sync blocks
- Add `Array` data descriptor
- Add `GetArrayData` to `Object` contract
- Introduces a dependency on `RuntimeTypeSystem` contract
- Make cDAC implement `ISOSDacInterface::GetObjectData` except for handling CCW/RCWs
- Returns E_NOTIMPL when runtime supports COM
- Validated in debugger that cDAC and DAC return the same values for some test single and multidimensional arrays
- Pull out shared test helpers for adding different data to the mock target
This is largely a placeholder just to get the MethodDesc/MethodDescChunk infrastructure in place. To further fill out ValidateMethodDesc and to implement the GetMethodDescData DAC API, I also need to add an executable code manager contract for mapping between native code pointer values and methods. I'd like to do that as a separate PR.
Debugged WinDbg enough to verify that GetMethodDescData is implemented enough to extract the correct MethodTable pointer value from a MethodDesc.
* start GetMethodDescDataImpl
* add MethodDesc and MethodDescChunk
* checkpoint: MethodDesc validation
* update contract
* fix RuntimeTypeSystem unit tests
mock the additional data and globals
* fix GetMethodDescChunkPointerMayThrow
* add data descriptor description to the contract
* Apply suggestions from code review
Co-authored-by: Elinor Fung <elfung@microsoft.com>
* MayThrow -> Throwing
* Slot is ushort not byte
* remove unused property
* add TargetPointer 32-/64-bit max constants
* use NewArrayHolder
* spelling
* add globals to RTS contract
* remove unused usings
* constexpr cdac_offsets, not const
* Apply suggestions from code review
Co-authored-by: Elinor Fung <elfung@microsoft.com>
* make GetNumVtableSlots private
---------
Co-authored-by: Elinor Fung <elfung@microsoft.com>
- Include `String` and `Object` in data descriptor
- Start an `Object` contract for getting information about known managed objects
- Make cDAC implement `ISOSDacInterface::GetObjectStringData`
- Add placeholder value in `apphost` for .NET install search options. Format:
- `<search_location_flags> /0 <app_relative_dotnet_path>`
- Make `apphost` conditionally look at app-local, app-relative, environment variables, and global locations based on configured behaviour
- Default (placeholder not changed) is to look at app-local, environment variables, and global locations.
- Update error and tracing messages to include information about any configured search options
- Allow specifying search options in `HostWriter.CreateAppHost`
- Add unit/integration tests
Part of https://github.com/dotnet/designs/blob/main/proposed/apphost-embed-install-location.md.
There still needs to be a corresponding change on the SDK side to allow configuration via `AppHostDotNetSearch` and `AppHostRelativeDotNet` properties.
Add new details to the RuntimeTypeSystem and Loader contracts as needed to load metadata and examine and identify all of the kinds of type that the CoreCLR type system can represent
Add a type name generator based on a line by line copy from the CoreCLR codebase
Add an Ecma335 metadata parser which is pure safe managed code, and is capable of loading metadata that is not structured as a single array. This implementation is heavily based on the dnmd implementation. It is intended that this implementation is short-lived, and really ought to be replaced by dnmd or System.Reflection.Metadata when those apis become suitable for use in this scenario.
Provide implementations and documentation for all of the new contracts except for the RW metadata one. (Its rarely needed, so we can add it later)
Enhance the target infrastructure to better handle various forms of arrays, and contracts which do math based on target pointer sizes.
Contributes to https://github.com/dotnet/runtime/issues/99302
* WorkingOnIt
* It basically works for a single example.
Baseline
Loader Heap:
----------------------------------------
System Domain: 7ffab916ec00
LoaderAllocator: 7ffab916ec00
LowFrequencyHeap: Size: 0xf0000 (983040) bytes total.
HighFrequencyHeap: Size: 0x16a000 (1482752) bytes total, 0x3000 (12288) bytes wasted.
StubHeap: Size: 0x1000 (4096) bytes total.
FixupPrecodeHeap: Size: 0x168000 (1474560) bytes total.
NewStubPrecodeHeap: Size: 0x18000 (98304) bytes total.
IndirectionCellHeap: Size: 0x1000 (4096) bytes total.
CacheEntryHeap: Size: 0x1000 (4096) bytes total.
Total size: Size: 0x3dd000 (4050944) bytes total, 0x3000 (12288) bytes wasted.
Compare
Loader Heap:
----------------------------------------
System Domain: 7ff9eb49dc00
LoaderAllocator: 7ff9eb49dc00
LowFrequencyHeap: Size: 0xef000 (978944) bytes total.
HighFrequencyHeap: Size: 0x1b2000 (1777664) bytes total, 0x3000 (12288) bytes wasted.
StubHeap: Size: 0x1000 (4096) bytes total.
FixupPrecodeHeap: Size: 0x70000 (458752) bytes total.
NewStubPrecodeHeap: Size: 0x10000 (65536) bytes total.
IndirectionCellHeap: Size: 0x1000 (4096) bytes total.
CacheEntryHeap: Size: 0x1000 (4096) bytes total.
Total size: Size: 0x324000 (3293184) bytes total, 0x3000 (12288) bytes wasted.
LowFrequencyHeap is 4KB bigger
HighFrequencyHeap is 288KB bigger
FixupPrecodeHeap is 992KB smaller
NewstubPrecodeHeap is 32KB smaller
* If there isn't a parent methodtable and the slot matches... then it by definition the method is defining the slot
* Fix a couple more issues found when running a subset of the coreclr tests
* Get X86 building again
* Attempt to use a consistent api to force slots to be set
* Put cache around RequiresStableEntryPoint
* Fix typo
* Fix interop identified issue where we sometime set a non Precode into an interface
* Move ARM and X86 to disable compact entry points
* Attempt to fix build breaks
* fix typo
* Fix another Musl validation issue
* More tweaks around NULL handling
* Hopefully the last NULL issue
* Fix more NULL issues
* Fixup obvious issues
* Fix allocation behavior so we don't free the data too early or too late
* Fix musl validation issue
* Fix tiered compilation
* Remove Compact Entrypoint logic
* Add new ISOSDacInterface15 api
* Fix some naming of NoAlloc to a more clear IfExists suffix
* Remove way in which GetTemporaryEntryPoint behaves differently for DAC builds, and then remove GetTemporaryEntrypoint usage from DAC entirely in favor of GetTemporaryEntryPointIfExists
* Attempt to reduce most of the use of EnsureSlotFilled. Untested, but its late.
* Fix the build before sending to github
* Fix unix build break, and invalid assert
* Improve assertion checks to validate that we don't allocate temporary entrypoints that will be orphaned if the type doesn't actually end up published.
* Remove unused parameters and add contracts
* Update method-descriptor.md
* Fix musl validation issue
* Adjust SOS api to be an enumerator
* Fix assertion issues noted
Fix ISOSDacInterface15 to actually work
* Remove GetRestoredSlotIfExists
- Its the same as GetSlot .... just replace it with that function.
* Update src/coreclr/debug/daccess/daccess.cpp
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
* Update docs/design/coreclr/botr/method-descriptor.md
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
* Update src/coreclr/vm/methodtable.inl
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
* Update src/coreclr/vm/methodtable.h
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
* Fix GetMethodDescForSlot_NoThrow
Try removing EnsureSlotFilled
Implement IsEligibleForTieredCompilation in terms of IsEligibleForTieredCompilation_NoCheckMethodDescChunk
* Fix missing change intended in last commit
* Fix some more IsPublished memory use issues
* Call the right GetSlot method
* Move another scenario to NoThrow, I think this should clear up our tests...
* Add additional IsPublished check
* Fix MUSL validation build error and Windows x86 build error
* Address code review feedback
* Fix classcompat build
* Update src/coreclr/vm/method.cpp
Co-authored-by: Aaron Robinson <arobins@microsoft.com>
* Remove assert that is invalid because TryGetMulticCallableAddrOfCode can return NULL ... and then another thread could produce a stable entrypoint and the assert could lose the race
* Final (hopefully) code review tweaks.
* Its possible for GetOrCreatePrecode to be called for cases where it isn't REQUIRED. we need to handle that case.
---------
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: Aaron Robinson <arobins@microsoft.com>
- Make cDac implement `ISOSDacInterface2`
- Add `Exception` (managed type) to data descriptor
- Add `GetExceptionData` to `Exception` contract which gets all the data that SOS-DAC API uses
- Start a `Loader` contract - currently contains what is needed for GetModuleData
- Implement `ISOSDacInterface::GetModuleData` in cDAC
- Store base address and is reflection emit bit on `Module` for easier diagnostics access
* Implement GetThreadStoreData in cDAC
* [dac] Return canonical MethodTable instead of EEClass
Instead of storing the EEClass pointer in DacpMethodTableData, store the canonical method table instead.
Correspondingly, update GetMethodTableForEEClass to expect a canonical method table pointer instead of an EEClass
Also update cDAC to do likewise
* document GetMethodTableData string baseSize adjustment
* Apply suggestions from code review
Co-Authored-By: Aaron Robinson <arobins@microsoft.com>
* [vm] rename ContainsPointers flag to ContainsGCPointers
also rename getter/setter methods in MethodTable
* code style suggestions from code review
* DAC: always set wNumVirtuals and wNumVtableSlots to 0
This information can be retreived from the MethodTable using normal lldb/windbg primitives and doesn't need to be part of the DAC API contract
* Remove NumVirtuals and NumVtableSlots from RuntimeTypeSystem.md
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
* "untrusted" -> "non-validated"
* pull test target helpers out
goal is to be able to use this for testing contracts that depend on some data in the heap
* Add one FreeObjectMethodTable unit test
* validate that a mock system object is a valid method table
* code review feedback and more tests:
1. rename AttrClass data descriptor field to CorTypeAttr
2. fixup HasComponentSize / RawGetComponentSize comments and code
3. update "system.object" mock methodtable with more field values
4. update "system.string" mock methodtable with more field values
* Update src/coreclr/gc/env/gcenv.object.h
Co-authored-by: Elinor Fung <elfung@microsoft.com>
* Update src/native/managed/cdacreader/src/Contracts/Metadata_1.MethodTableFlags.cs
Co-authored-by: Elinor Fung <elfung@microsoft.com>
* move non-validated MethodTable handling to a separate class
* clear up ComponentSize contract spec and impl
* rename Metadata -> RuntimeTypeSystem
* add validation failure test; change validation to throw InvalidOperationException
* Update src/native/managed/cdacreader/src/Contracts/RuntimeTypeSystem_1.cs
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
* Add a generic instance test
* add array instance test
---------
Co-authored-by: Elinor Fung <elfung@microsoft.com>
Co-authored-by: Aaron Robinson <arobins@microsoft.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
This change makes access to statics much simpler to document and also removes some performance penalties that we've had for a long time due to the old model. Most statics access should be equivalent or faster.
This change converts static variables from a model where statics are associated with the module that defined the metadata of the static to a model where each individual type allocates its statics independently. In addition, it moves the flags that indicate whether or not a type is initialized, and whether or not its statics have been allocated to the `MethodTable` structures instead of storing them in a `DomainLocalModule` as was done before.
# Particularly notable changes
- All statics are now considered "dynamic" statics.
- Statics for collectible assemblies now have an identical path for lookup of the static variable addresses as compared to statics for non-collectible assemblies. It is now reasonable for the process of reading static variables to be inlined into shared generic code, although this PR does not attempt to do so.
- Lifetime management for collectible non-thread local statics is managed via a combination of a `LOADERHANDLE` to keep the static alive, and a new handle type called a `HNDTYPE_WEAK_INTERIOR_POINTER` which will keep the pointers to managed objects in the `MethodTable` structures up to date with the latest addresses of the static variables.
- Each individual type in thread statics has a unique object holding the statics for the type. This means that each type has a separate object[](for gc statics), and/or double[](for non-gc statics) per thread for TLS statics. This isn't necessarily ideal for non-collectible types, but its not terrible either.
- Thread statics for collectible types are reported directly to the GC instead of being handled via a GCHandle. While needed to avoid complex lifetime rules for collectible types, this may not be ideal for non-collectable types.
- Since the `DomainLocalModule` no longer exists, the `ISOSDacInterface` has been augmented with a new api called `ISOSDacInterface14` which adds the ability to query for the static base/initialization status of an individual type directly.
- Significant changes for generated code include
- All the helpers are renamed
- The statics of generics which have not yet been initialized can now be referenced using a single constant pointer + a helper call instead of needing a pair of pointers. In practice, this was a rare condition in perf-critical code due to the presence of tiered compilation, so this is not a significant change to optimized code.
- The pre-initialization of statics can now occur for types which have non-primitive valuetype statics as long as the type does not have a class constructor.
- Thread static non-gc statics are now returned as byrefs. (It turns out that for collectible assemblies, there is currently a small GC hole if a function returns the address of a non-gc threadstatic. CoreCLR at this time does not attempt to keep the collectible assembly alive if that is the only live pointer to the collectible static in the system)
With this change, the pointers to normal static data are located at a fixed offset from the start of the `MethodTableAuxiliaryData`, and indices for Thread Static variables are stored also stored in such a fixed offset. Concepts such as the `DomainLocalModule` , `ThreadLocalModule`, `ModuleId` and `ModuleIndex` no longer exist.
# Lifetime management for collectible statics
- For normal collectible statics, each type will allocate a separate object[] for the GC statics and a double[] for the non-GC statics. A pointer to the data of these arrays will be stored in the `DynamicStaticsInfo` structure, and when relocation occurs, if the collectible types managed `LoaderAllocator` is still alive, the static field address will be relocated if the object moves. This is done by means of the new Weak Interior Pointer GC handle type.
- For collectible thread-local statics, the lifetime management is substantially more complicated due the issue that it is possible for either a thread or a collectible type to be collected first. Thus the collection algorithm is as follows.
- The system shall maintain a global mapping of TLS indices to MethodTable structures
- When a native `LoaderAllocator` is being cleaned up, before the WeakTrackResurrection GCHandle that points at the the managed `LoaderAllocator` object is destroyed, the mapping from TLS indices to collectible `LoaderAllocator` structures shall be cleared of all relevant entries (and the current GC index shall be stored in the TLS to MethodTable mapping)
- When a GC promotion or collection scan occurs, for every TLS index which was freed to point at a GC index the relevant entry in the TLS table shall be set to NULL in preparation for that entry in the table being reused in the future. In addition, if the TLS index refers to a `MethodTable` which is in a collectible assembly, and the associated `LoaderAllocator` has been freed, then set the relevant entry to NULL.
- When allocating new entries from the TLS mapping table for new collectible thread local structures, do not re-use an entry in the table until at least 2 GCs have occurred. This is to allow every thread to have NULL'd out the relevant entry in its thread local table.
- When allocating new TLS entries for collectible TLS statics on a per-thread basis allocate a `LOADERHANDLE` for each object allocated, and associate it with the TLS index on that thread.
- When cleaning up a thread, for each collectible thread static which is still allocated, we will have a `LOADERHANDLE`. If the collectible type still has a live managed `LoaderAllocator` free the `LOADERHANDLE`.
# Expected cost model for extra GC interactions associated with this change
This change adds 3 possible ways in which the GC may have to perform additional work beyond what it used to do.
1. For normal statics on collectible types, it uses the a weak interior pointer GC handle for each of these that is allocated. This is purely pay for play and trades off performance of accessing collectible statics at runtime to the cost of maintaining a GCHandle in the GC. As the number of statics increases, this could in theory become a performance problem, but given the typical usages of collectible assemblies, we do not expect this to be significant.
2. For non-collectible thread statics, there is 1 GC pointer that is unconditionally reported for each thread. Usage of this removes a single indirection from every non-collectible thread local access. Given that this pointer is reported unconditionally, and is only a single pointer, this is not expected to be a significant cost.
3. For collectible thread statics, there is a complex protocol to keep thread statics alive for just long enough, and to clean them up as needed. This is expected to be completely pay for play with regard to usage of thread local variables in collectible assemblies, and while slightly more expensive to run than the current logic, will reduce the cost of creation/destruction of threads by a much more significant factor. In addition, if there are no collectible thread statics used on the thread, the cost of this is only a few branches per lookup.
# Perf impact of this change
I've run the .NET Microbenchmark suite as well as a variety of ASP.NET Benchmarks. (Unfortunately the publicly visible infrastructure for running tests is incompatible with this change, so results are not public). The results are generally quite hard to interpret. ASP.NET Benchmarks are generally (very) slightly better, and the microbenchmarks are generally equivalent in performance, although there is variability in some tests that had not previously shown variability, and the differences in performance are contained within the margin of error in our perf testing for tests with any significant amount of code. When performance differences have been examined in detail, they tend to be in code which has not changed in any way due to this change, and when run in isolation the performance deltas have disappeared in all cases that I have examined. Thus, I assume they are caching side effect changes. Performance testing has led me to add a change such that all NonGC, NonCollectible statics are allocated in a separate LoaderHeap which appears to have reduced the variability in some of the tests by a small fraction, although results are not consistent enough for me to be extremely confident in that statement.
- Implement `GetThreadStoreData` and `GetThreadCounts` in `Thread` contract
- Finish implementing `ISOSDacInterface::GetThreadStoreData` in cDAC
- Add specific threads (first in thread store, Finalizer, GC) and counts
- Make existing DAC call into cDAC for `GetThreadData` if available
- Only fills out managed thread ID and next thread right now - always returns E_NOTIMPL
- Update the example C# API in docs to be closer to what we have now
* Change the ReciprocalEstimate and ReciprocalSqrtEstimate APIs to be mustExpand on RyuJIT
* Apply formatting patch
* Fix the RV64 and LA64 builds
* Mark the ReciprocalEstimate and ReciprocalSqrtEstimate methods as AggressiveOptimization to bypass R2R
* Mark other usages of ReciprocalEstimate and ReciprocalSqrtEstimate in Corelib with AggressiveOptimization
* Mark several non-deterministic APIs as BypassReadyToRun and skip intrinsic expansion in R2R
* Cleanup based on PR recommendations to rely on the runtime rather than attributation of non-deterministic intrinsics
* Adding a regression test ensuring direct and indirect invocation of non-deterministic intrinsic APIs returns the same result
* Add a note about non-deterministic intrinsic expansion to the botr
* Apply formatting patch
* Ensure vector tests are correctly validating against the scalar implementation
* Fix the JIT/SIMD/VectorConvert test and workaround a 32-bit test issue
* Skip a test on Mono due to a known/tracked issue
* Ensure that lowering on Arm64 doesn't make an assumption about cast shapes
* Ensure the tier0opts local is used
* Ensure impEstimateIntrinsic bails out for APIs that need to be implemented as user calls
- Map indirect global values to corresponding values in `pointer_data` array from contract descriptor
- Add `[Try]Read<T>`, `[Try]ReadPointer`, `[Try]ReadGlobal<T>` and `[Try]ReadGlobalPointer` to `Target`
- Make cDAC implementation of `ISOSDacInterface9.GetBreakingChangeVersion` read value from globals
- Create test helpers for mocking out reading from the target and providing a contract descriptor for different bitness/endianness
- Add unit tests for reading global values (direct and indirect)
# cDAC Build Tool
## Summary
The purpose of `cdac-build-tool` is to generate a `.c` file that contains a JSON cDAC contract descriptor.
It works by processing one or more object files containing data descriptors and zero or more text
files that specify contracts.
## Running
```console
% cdac-build-tool compose [-v] -o contractdescriptor.c -c contracts.txt datadescriptor.o
```
## .NET runtime build integration
`cdac-build-tool` is meant to run as a CMake custom command.
It consumes a target platform object file and emits a C source
file that contains a JSON contract descriptor. The C source
is the included in the normal build and link steps to create the runtime.
The contract descriptor source file depends on `contract-aux-data.c` which is a source file that contains
the definitions of the "indirect pointer data" that is referenced by the data descriptor. This is typically the addresses of important global variables in the runtime.
Constants and build flags are embedded directly in the JSON payload.
Multiple data descriptor source files may be specified (for example if they are produced by different components of the runtime, or by different source languages). The final JSON payload will be a composition of all the data descriptors.
Multiple contracts text files may be specified. This may be useful if some contracts are conditionally included (for example if they are platform-specific). The final JSON payload will be a composition of all the contracts files.
```mermaid
flowchart TB
headers("runtime headers")
data_header("datadescriptor.h")
data_src("datadescriptor.c")
compile_data["clang"]
data_obj("datadescriptor.o")
contracts("contracts.txt")
globals("contractpointerdata.c")
build[["cdac-build-tool"]]
descriptor_src("contractdescriptor.c")
vm("runtime sources")
compile_runtime["clang"]
runtime_lib(["libcoreclr.so"])
headers -.-> data_src
headers ~~~ data_header
data_header -.-> data_src
headers -.-> globals
headers -.-> vm
data_src --> compile_data --> data_obj --> build
contracts ---> build
build --> descriptor_src
descriptor_src --> compile_runtime
data_header -.-> globals ----> compile_runtime
vm ----> compile_runtime --> runtime_lib
```
---
* add implementation note notes
* add an emitter
* read in the directory header
* contract parsing
* indirect pointer value support
* move sample to tool dir
* Take baselines from the docs/design/datacontracts/data dir
We don't parse them yet, however
* Add README
* fix BE
Store the magic as a uint64_t so that it will follow the platform endianness.
Store endmagic as bytes so that it directly follows the name pool - and fix the endmagic check not to look at the endianness
* hook up cdac-build-tool to the coreclr build; export DotNetRuntimeContractDescriptor
* cleanup; add contracts.txt
* add diagram to README
* move implementation notes
* better verbose output from ObjectFileScraper
* turn off whole program optimizations for data-descriptor.obj
On windows /GL creates object files that cdac-build-tool cannot read
It's ok to do this because we don't ship data-descriptor.obj as part of the product - it's only used to generate the cDAC descriptor
* C++-ify and add real Thread offsets
* no C99 designated initializers in C++ until C++20
* build data descriptor after core runtime
* fix gcc build
* simplify ObjectFileScraper
just read the whole file into memory
* invoke 'dotnet cmake-build-tool.dll' instead of 'dotnet run --project'
* clean up macro boilerplate
* platform flags
* turn off verbose output
* can't use constexpr function in coreclr
because debugreturn.h defines a `return` macro that expands to something that is not c++11 constexpr
* Rename "aux data" to "pointer data"
* rename "data-descriptor" to "datadescriptor"
* simplify linking
* cdac-build-tool don't build dotnet tool; turn on analyzers
* rationalize naming; update docs; add some inline comments
* renamce cdac.h to cdacoffsets.h
* improve output: hex offsets; improved formatting
* don't throw in ParseContracts; add line numbers to errors
* change input format for contracts to jsonc
* add custom JsonConverter instances for the compact json representation
* simplify; bug fix - PointerDataCount include placeholder
* one more set of feedback changes: simpler json converters
* set _RequiresLiveILLink=false for cdac-build-tool.csproj
fixes windows builds:
error MSB3026: (NETCORE_ENGINEERING_TELEMETRY=Build) Could not copy "D:\a\_work\1\s\artifacts\obj\ILLink.Tasks\Debug\net9.0\ILLink.Tasks.dll" to "D:\a\_work\1\s\artifacts\bin\ILLink.Tasks\Debug\net9.0\ILLink.Tasks.dll". Beginning retry 1 in 1000ms. The process cannot access the file 'D:\a\_work\1\s\artifacts\bin\ILLink.Tasks\Debug\net9.0\ILLink.Tasks.dll' because it is being used by another process.
---------
Co-authored-by: Elinor Fung <elfung@microsoft.com>
Co-authored-by: Aaron Robinson <arobins@microsoft.com>
* Replace FEATURE_EH_FUNCLETS/FEATURE_EH_CALLFINALLY_THUNKS in JIT with runtime switch
* Cache Native AOT ABI check to see if TP improves
---------
Co-authored-by: Bruce Forstall <brucefo@microsoft.com>
Building on #100253 , describe an in-memory representation of the toplevel contract descriptor, comprisied of:
* some target architecture properties
* a data descriptor
* a collection of compatible contracts
Contributes to #99298
Fixes https://github.com/dotnet/runtime/issues/99299
---
* [cdac] Physical contract descriptor spec
* Add "contracts" to the data descriptor
* one runtime per module
if there are multiple hosted runtimes, diagnostic tooling should look in each loaded module to discover the contract descriptor
* Apply suggestions from code review
* Review feedback
- put the aux data and descriptor sizes closer to the pointers
- Don't include trailing nul `descriptor_size`. Clarify it is counting bytes and that `descriptor` is in UTF-8
- Simplify `DotNetRuntimeContractDescriptor` naming discussion
---------
Co-authored-by: Elinor Fung <elfung@microsoft.com>
Contributes to #100162 which is part of #99298
Follow-up to #99936 that removes "type layout" and "global value" contracts and instead replaces them with a "data descriptor" blob.
Conceptually a particular target runtime provides a pair of a logical data descriptor together with a set of algorithmic contract versions. The logical data descriptor is just a single model that defines all the globals and type layouts relevant to the set of algorithmic contract versions.
A logical data descriptor is realized by merging two physical data descriptors in a proscribed order.
The physical data descriptors provide some subset of the type layouts or global values.
The physical data descriptors come in two flavors:
- baseline descriptors that are checked into the dotnet/runtime repo and have well -known names
- in-proc descriptors that get embedded into a target runtime.
Each in-proc descriptor may refer to a baseline and represents a delta applied on top of the baseline.
The data contract model works on top of a flattened logical data descriptor.
Co-authored-by: Aaron Robinson <arobins@microsoft.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: Noah Falk <noahfalk@users.noreply.github.com>
The operation of `mkrefany` can easily be represented with more
generally handled nodes within the JIT today. This also allows promotion
to remain enabled for methods using this construct, so CQ improvements
are expected when optimizing.
* Initial spec for the meaning and relationships between data contracts
* Adjust to feedback
* actually inclde the new spec in the new location
* Merge in Jan's preamble
* Add total type size to the layout info.
* Add example algorithmic contracts
- To start, I've added the contracts for iterating the thread list and gathering information about individual threads
- Note that this algorithmic description is paired with a simplification of the SList data structure
- See PR #100107
* Tweaks to some of the algorithms as suggested by Jan
* [mono] Add old design docs from mono website.
The original location of these documents is:
https://github.com/mono/website/tree/gh-pages/docs/advanced/runtime/docs
Changes made:
- renamed BITCODE.md -> bitcode.md
- removed some documents like xdebug.md which are no longer relevant
* Update docs/design/mono/web/coop-suspend.md
Co-authored-by: Aleksey Kliger (λgeek) <akliger@gmail.com>
* Convert the title/redirect_from block to a H1.
---------
Co-authored-by: Aleksey Kliger (λgeek) <akliger@gmail.com>
* Generic type support
Instance and static fields on generic types
Re-enable and add to field tests
Generic types with non-generic methods.
Generic static methods
* Native AOT support
* Add design document
Add strict check for precisely matched Generic constraints
