Consider to rewrite ILasm/ILdasm in C#

[huoyaoyuan]

During the cleanup of PAL simulated I/O functions, ILasm/ILdasm are the remaining components that using them heavily. The codebase of these tools are already quite a mess that written in ancient style (C++ 9x). It appears that a complete rewrite can provide more benefit and clean up more utility code.

The benefits for using native code instead of managed code:

• Better support for source-build bootstrapping
• Use the same loading/emit code of runtime (DNMD in the future)

The plan is to rewrite one first (probably ildasm) and test round-tripping with counterpart of old version.

@jkotas @jkoritzinsky @AaronRobinsonMSFT Any thoughts? Do you think it's better to use native code or managed code?

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT
See info in area-owners.md if you want to be subscribed.

[AaronRobinsonMSFT]

@jkoritzinsky Had started a C# rewrite a few years ago, unclear where that is at present.

It appears that a complete rewrite can provide more benefit and clean up more utility code.

That is true, the cost is the issue. Both tools are the backbone of a lot of testing and as a result have a myriad of quirks that enable comprehensive testing and permit emitting invalid IL, but not always. There is also the non-trivial IL grammer, we would need a new parser generator or to write one from scratch in managed - both of which are going to be tricky. The tricky bit is ensuring we have the flexibility we and the few people that use IL directly expect.

The managed vs native discussion follows from the previous paragraph. Using native would allow us to keep the parser and do it incrementally, but moving to managed is really the direction we want for a lot of this sort of work - ideally something that could be AOT compiled in the end.

My suggestion here would be to continue to do what you and various other members have been doing in this space, incremental rewrites to small portions of it. I don't think there is going to be a lot of success doing a full rewrite to managed in any reasonable timeframe, Jeremy's work might be close after several years, and so incremental rewrites of the C++ version seem appropriate for now.

Thank you for this issue. I assume you know this, but for everyone, seeing a PR at some future date for a complete rewrite of the IL tools isn't something we're likely to accept. Doing this incrementally or a rewrite with a highly detailed plan for testing and validation against the current implementation to ensure identical behavior and reliability is the only way to move forward with this.

/cc @tannergooding

[huoyaoyuan]

Thank you for your information. My main intention is to significantly rewrite the mechanical data structure/IO manipulation code in intermediate layer, while keeping the core parsing logic. This will allow cleaning up the manual string/collection usages. Doing this incrementally will result in horrible-looking format conversions in the boundaries, but it could still work reliably. And we shouldn't be so concerned about the performance in intermediate state.

Additional question: is it free to use C++ exceptions and basic STL containers in pure-native component?

[jkotas]

If we are going to spend any time on rewriting ilasm/ildasm, it should be rewrite in C#. I do not think rewriting it in modern C++ is a good use of time.

[jkotas]

I am fine with local refactorings like you have been doing that allow us to get rid of Win32 PAL.

[jkotas]

Jeremy's work

We may want to put this work somewhere where multiple people can collaborate on stabilizing it. I think it can even be main as non-shipping project.

[jkoritzinsky]

When I'm back I'll update my branch to a recent main and put a PR. Then we can decide where it should live.

[agocke]

Doing this incrementally or a rewrite with a highly detailed plan for testing and validation against the current implementation to ensure identical behavior and reliability is the only way to move forward with this.

I would even suggest the end goal may be to ship both together for a while, run both, compare the outputs, and error if they're different (with a -classic fallback flag).

My experience with Roslyn is that bug-for-bug compat is painful

[jkotas]

bug-for-bug compat

I am worried about that. ilasm/ildasm has multiple orders of magnitude smaller exposure compared to Roslyn, and it is only distributed as a standalone package so in case somebody runs into a blocking bug, it is not expensive to stay pinned to an old version until the blocker is fixed.

I would say that once we are able to compile and roundtrip what we have in this repo using old/new mix, we are in a good enough shape to switch.