This repository has been archived by the owner on Nov 1, 2020. It is now read-only.
Add basic build scripts #2
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Files under src/Native have been copied from https://github.com/dotnet/corefx/tree/master/src/Native The root build.sh file has been copied from https://github.com/dotnet/corefx Commit label in the corefx repo: dbb131dcafe570fd93824820797c88eb35609fc7 Note: - Some minor cleanup has been done build.sh, src/Native/CMakeLists.txt and src/Native/configure.cmake: renamed corefx -> corert, removed corefx specific parts - No code builds yet with this change
|
LGTM |
This was referenced Jan 27, 2016
jkotas
pushed a commit
that referenced
this pull request
Feb 2, 2017
…h an export function. [tfs-changeset: 1646428]
ghost
mentioned this pull request
Open
trylek
referenced
this pull request
in trylek/corert
Jul 20, 2018
In this part I have mechanically moved parts of CorInfoImpl to be forked to both CorInfoImpl.RyuJit and CorInfoImpl.ReadyToRun. I decided not to move getFieldInfo for now as it's a lengthy method and right now I'm only changing one line in it so that conditional compilation should be sufficient. We can fork it later if the changes become more pronounced e.g. due to the differences in thread static bases. The full list of methods I'm moving in this change is as follows: (*) ComputeLookup (*) getReadyToRunHelper (*) getReadyToRunDelegateCtorHelper (*) GetHelperFtnUncached (*) getFunctionEntryPoint (*) constructStringLiteral Apart from the mechanical move I have made a few other minor changes: 1) I have changed the hard-coded CORINFO_RUNTIME_ABI to a symbolic constant that is defined in CII.RJ and CII.RTR. In this one simple case I have already "executed" the split by putting the appropriate constant into each file, otherwise I left the moved methods unchanged for now. 2) I have made one additional change I overlooked in my previous cleanup change: I modified getHelperFtn by adding optional support for indirection cells that are used for the helpers in R2R. As mentioned above, for now I assume that I'll deal with the differences in getCallInfo and getFieldInfo using Thanks Tomas
trylek
referenced
this pull request
in trylek/corert
Jul 20, 2018
In this part I have mechanically moved parts of CorInfoImpl to be forked to both CorInfoImpl.RyuJit and CorInfoImpl.ReadyToRun. I decided not to move getFieldInfo for now as it's a lengthy method and right now I'm only changing one line in it so that conditional compilation should be sufficient. We can fork it later if the changes become more pronounced e.g. due to the differences in thread static bases. The full list of methods I'm moving in this change is as follows: (*) ComputeLookup (*) getReadyToRunHelper (*) getReadyToRunDelegateCtorHelper (*) GetHelperFtnUncached (*) getFunctionEntryPoint (*) constructStringLiteral Apart from the mechanical move I have made a few other minor changes: 1) I have changed the hard-coded CORINFO_RUNTIME_ABI to a symbolic constant that is defined in CII.RJ and CII.RTR. In this one simple case I have already "executed" the split by putting the appropriate constant into each file, otherwise I left the moved methods unchanged for now. 2) I have made one additional change I overlooked in my previous cleanup change: I modified getHelperFtn by adding optional support for indirection cells that are used for the helpers in R2R. As mentioned above, for now I assume that I'll deal with the differences in getCallInfo and getFieldInfo using Thanks Tomas
trylek
added a commit
that referenced
this pull request
Jul 20, 2018
In this part I have mechanically moved parts of CorInfoImpl to be forked to both CorInfoImpl.RyuJit and CorInfoImpl.ReadyToRun. I decided not to move getFieldInfo for now as it's a lengthy method and right now I'm only changing one line in it so that conditional compilation should be sufficient. We can fork it later if the changes become more pronounced e.g. due to the differences in thread static bases. The full list of methods I'm moving in this change is as follows: (*) ComputeLookup (*) getReadyToRunHelper (*) getReadyToRunDelegateCtorHelper (*) GetHelperFtnUncached (*) getFunctionEntryPoint (*) constructStringLiteral Apart from the mechanical move I have made a few other minor changes: 1) I have changed the hard-coded CORINFO_RUNTIME_ABI to a symbolic constant that is defined in CII.RJ and CII.RTR. In this one simple case I have already "executed" the split by putting the appropriate constant into each file, otherwise I left the moved methods unchanged for now. 2) I have made one additional change I overlooked in my previous cleanup change: I modified getHelperFtn by adding optional support for indirection cells that are used for the helpers in R2R. As mentioned above, for now I assume that I'll deal with the differences in getCallInfo and getFieldInfo using #ifdef READYTORUN. Thanks Tomas
jkotas
pushed a commit
that referenced
this pull request
Aug 8, 2018
The issue is that the RhpRethrow stubs do not initialize the values of m_kind for the ExInfo objects they allocate on stack. Depending on the kind of garbage that gets assigned to m_kind, the stack iterator either takes the code path of reporting the gcroots of the RhpRethrow callsite, or takes the code path with the RemapHardwareFaultToGCSafePoint (if m_kind ends up getting a HW exception flag).
The piece of code that initializes the m_kind field of the ExInfo object on rethrows is in ExceptionHandling.cs, and there’s a window of opportunity where GC collection can happen before m_kind gets initialized correctly.
The bug needs the following conditions to occur:
1) Garbage value in ExInfo.m_kind before initialization causes the stack iterator to take one code path, then after initialization take the other code path.
2) GC collection happens in the middle, before m_kind gets properly initialized
3) Gc roots reported in each of the 2 different code paths are different
4) The GC collection in step #2 causes a relocation of a reference object of interest.
The fix is to just initialize the field to something deterministic that makes sense (zero in that case). This would cause the stack iterator to use the gcroots reporting of the RhpRethrow callsite, until the field is initialized to a more meaningful value (ex: in case of a rethrow of a HW exception) where we would apply the correct algorithm to determine a more correct gcroots reporting point to use based on where execution is headed (ex: use the gcroots reporting point of a finally block if the rethrow is for a HW exception, and in a catch block)
[tfs-changeset: 1709684]
jkotas
pushed a commit
that referenced
this pull request
Aug 21, 2018
The ProjectN compiler never finishes compiling an app from an external use. The issue turns out to be due to the debug recording generation for a huge generic expansion. There are actually two problems: 1. The generic complexity computation is improper for the huge generic expansion in the failing case. The complexity computed was 0 and the compiler didn’t know it’s huge. 2. We are missing the check against the generic complexity in some places where UDT debug records are prepared. Fixing #1 at this point is tricky since it may cause wide asm diffs where normal calls become USG calls. Fixing #2 means the UDT types in the debug$T section for huge generic instantiations will fall back to USG or canonical records, so will the debug$S records for associated static fields. The debug$T change should only affect native debugging. The debug$S change can affect managed debugging but only for huge generic instantiations. We've decided #2 is probably the less risky way to unblock the user in the next release and it's fixed by this change for both ProjectN and ProjectX. [tfs-changeset: 1711506]
dotnet-maestro-bot
pushed a commit
to dotnet-maestro-bot/corert
that referenced
this pull request
Sep 4, 2018
* Fix ServiceController name population perf * Split tests * Remove dead field * Remove new use of DangerousGetHandle * SafeHandle all the things! * VSB dotnet#1 * VSB dotnet#2 * Fix GLE * Initialize machineName in ctor * Test for empty name ex * Null names * Inadvertent edit * Unix build * Move interop into class * Reverse SafeHandle for HAllocGlobal * Fix tests * Disable test for NETFX * CR feedback * Pattern matching on VSB * Direct call * typo Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
jkotas
pushed a commit
that referenced
this pull request
Sep 5, 2018
* Fix ServiceController name population perf * Split tests * Remove dead field * Remove new use of DangerousGetHandle * SafeHandle all the things! * VSB #1 * VSB #2 * Fix GLE * Initialize machineName in ctor * Test for empty name ex * Null names * Inadvertent edit * Unix build * Move interop into class * Reverse SafeHandle for HAllocGlobal * Fix tests * Disable test for NETFX * CR feedback * Pattern matching on VSB * Direct call * typo Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
trylek
added a commit
that referenced
this pull request
May 20, 2019
This change modifies the existing --inputbubble CPAOT option to work the same as Crossgen /largeversionbubble i.e. the main module and all reference assemblies are considered to belong to the same version bubble. The gist of the change deals with encoding module overrides in signatures. I have implemented a new R2R header table ManifestMetadataTableNode and added logic for composing and emitting the extra AssemblyRef list. One challenging bit was that we need to emit all the signatures before emitting the ManifestMetadataTableNode because only the emission of the signatures shakes out all the required AssemblyRef's. I have added a simple loop to ImportSectionsTableNode / ImportSectionNode that traverses and emits all registered import cell signatures. For instance entrypoints, I didn't find any manner of encoding a module override for their signatures in the native hashtable so for now I added filtering that we're only storing those instance entrypoints that have the current input module as the reference module. One can theoretically imagine that a module may contain arbitrary generic instantiations spanning other modules when larger bubbles are on. While working on the change I also realized that the current way of basing signature contexts on input modules in CorInfoImpl.ReadyToRun was incorrect - when a method gets inlined, we still need the original signature context because that's what defines the ambient module used in the CoreCLR signature parser. I have deleted the field and instead I added a new method GetSignatureContext which currently returns ReadyToRunCoregenNodeFactory.InputModuleContext. Once we start implementing "single-file" (i.e. compiling multiple MSIL modules into a single PE), we'll change this to something more fine-grained, most likely based on some lookup on MethodBeingCompiled. I found out that part of the framework libraries were crashing in release build with large version bubble on due to the presence of duplicate symbols. I found out that CPAOT was still inconsistent w.r.t. means for formatting typesystem entities in AppendMangledName methods. I went over all these methods and unified them to use the name mangled for formatting types, methods and fields. As part of this cleanup I could subsequently remove the WriteTo methods on RuntimeDeterminedTypeHelper that are no longer needed. Rerunning the Pri#1 tests with my new support for issues.targets filtering out some annoying timing out GC tests I found out that several tests failed during CPAOT compilation in the manifest metadata table node. It turns out that the AssemblyRef metadata table is not always unique, in particular I hit duplication of the "mscorlib" reference in the table. This change makes CPAOT resilient towards this type of issues. Based on PR discussion I have modified the R2R single assembly compilation module group to keep input assemblies separate from the version bubble module set. With this change, CPAOT dependency analysis no longer attempts to compose the code graph across all assemblies, not only those being actually compiled, while keeping the more relaxed inlining conditions in case of larger version bubble. Based on this additional delta I could finally remove the artificial filtering of methods in MethodEntryPointTableNode. To facilitate this clean separation, I have added two new methods to CompilationModuleGroup for the version bubble checks - VersionsWithType and VersionsWithMethodBody. I have subsequently audited all CompilationModuleGroup queries in the CPAOT compiler and I changed the checks semantically referring to the version bubble to use the new methods. When determining reference module for encoding type signatures, we're special-casing primitive types as they don't need any reference module and use special constants in the signature encoding scheme. I previously didn't realize that object and string need the same treatment. I have also added an explanatory comment to Program.cs as to why we're using a try block when opening reference modules. Thanks Tomas
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Files under src/Native have been copied from
https://github.com/dotnet/corefx/tree/master/src/Native
The root build.sh file has been copied from
https://github.com/dotnet/corefx
Commit label in the corefx repo: dbb131dcafe570fd93824820797c88eb35609fc7
Note:
- Some minor cleanup has been done build.sh, src/Native/CMakeLists.txt
and src/Native/configure.cmake: renamed corefx -> corert, removed
corefx specific parts
- No code builds yet with this change