Use an ObjectWriter-based PE writer for crossgen2 #120454
Conversation
…ctory code a little
… need real unwind/debug info for R2R in the same way that NAOT does
…we needed this are CodeView debug sections, which aren't supported in PE files
… top of PEObjectWriter/ObjectWriter
…e runtime functions data into .pdata
…to ObjectWriter and move R2R usage over to be based on that.
…pple will use it (only Mach-O uses it)
…of it) can be used from within the ObjectWriter when provided.
…te a file on disk in the new path. (Does it work? That's the next step)
|
/azp run runtime-coreclr r2r-extra, runtime-coreclr r2r, runtime-coreclr crossgen2, runtime-coreclr crossgen2 outerloop, runtime-coreclr crossgen2-composite |
|
Azure Pipelines successfully started running 5 pipeline(s). |
|
My analysis of the failures: crossgen2-composite is in main: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1173552&view=ms.vss-test-web.build-test-results-tab r2r-extra: There's inconsistent occurrences of flaky tests like the ones I'm seeing here (stackoverflowtester in particular shows up quite a bit). The TestReadyToRun_Libraries runs were broken due to an infra issue. Running them again now. |
|
/azp run runtime-coreclr crossgen2 |
|
Azure Pipelines successfully started running 1 pipeline(s). |
...piler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/DelayLoadMethodCallThunkNodeRange.cs
Outdated
Show resolved
Hide resolved
...aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/Target_ARM64/ImportThunk.cs
Show resolved
Hide resolved
src/coreclr/tools/Common/Compiler/DependencyAnalysis/Target_ARM64/ARM64Emitter.cs
Show resolved
Hide resolved
davidwrighton
left a comment
davidwrighton
left a comment
There was a problem hiding this comment.
Looks good. I have a few issues I'd like to see you address/file a bug for, but otherwise thumbs up
agocke
left a comment
agocke
left a comment
There was a problem hiding this comment.
LGTM although I see a few FIXME comments. Might be worth having bugs for those
… every marked node.
|
/ba-g Windows arm64 queue is currently dead. |
5 participants
Today, crossgen2 uses its own PE builder built on top of
System.Reflection.PortableExecutable. However, this implementation ends up manually redoing the vast majority of the featuresSystem.Reflection.PortableExecutableprovides manually to support a number of edge cases that the library does not provide. Additionally, we plan to introduce a ReadyToRun format based on Mach-O (see #120065). There is no library likeSystem.Reflection.PortableExecutablewith a similar API that we could use for the Mach-O format, so we will either need to add some parallel path or move the PE path to something that can be shared with the Mach-O support.For NativeAOT's ILCompiler, we use an
ObjectWriterlibrary based loosely around LibObjectFile to enable us to write COFF, ELF, and Mach-O objects. This library provides a consistent API for all three formats.This PR changes crossgen2 to use a PE writer based on the COFF object writer from our
ObjectWriterlibrary. Additionally, this PR adds a number of features to theObjectWriterlibrary to support various constructs that are necessary for emitting a ReadyToRun image (symbol ranges, node size "relocs", deterministic file checksums, etc.).This should make completing #120065 much easier as the vast majority of the "How do we emit code/data correctly so we can meet Apple's requirements?" question is already met by the
MachObjectWriterin theObjectWriterlibrary, leaving a much smaller tail of work when adding support for it.