Open lambdageek opened 2 months ago
Tagging subscribers to this area: @hoyosjs See info in area-owners.md if you want to be subscribed.
With these new requirements, is there interest in NativeAOT-ing it with the live-built NativeAOT runtime instead of the LKG SDK?
With these new requirements, is there interest in NativeAOT-ing it with the live-built NativeAOT runtime instead of the LKG SDK?
I think that would be a nice bonus.
It's a long term goal for cdac to be distributed out of band (so any new enough cdac can be used to examine a released .NET9+ runtime). So the shipping/packaging story will change.
But for a runtime developer inner loop it would certainly be nice that a live NativeAOT can build a live cdacreader which can debug a live CoreCLR as it runs tests
a live NativeAOT can build a live cdacreader which can debug a live CoreCLR as it runs tests
If you are doing more intrusive changes in the runtime, live Native AOT is likely going to be broken too, and you are stuck with no debugging tools. I think using live NativeAOT to build tools is not helping with making us more productive.
The original
src/native/managed
infrastructure was developed with the idea that we need to buildlibcdacreader.so
/cdacreader.dll
(orlibcdacreader.a
/cdacreader.a
before static library support was abandoned) ahead of the main CoreCLR build so that we can link to the shared library during the CoreCLR build (specifically during the DAC build).But we don't do that now. Instead the DAC shared library dynamically loads the cDAC using
dlopen
/LoadLibrary
That means we don't have a true build-time dependency between the cDAC and the rest of the CoreCLR build. So we don't need to hook it in via
runtime-prereqs.proj
. We can add it as a separate subset or as aProjectReference
some place else. The only requirements are:This is also a first step for any plan to publish the cdacreader separately from the runtime (which is a long-term goal of the cdac effort: it should be possible to distribute and use cdacreader out of band)