ReadyToSpy

[cshung]

ReadyToSpy

I am writing this issue as a proposed new feature in ILSpy called ReadyToSpy.

Background

.NET Core introduced ReadyToRun, a new file format that contains pre-compiled native code, together with some useful metadata to describe the native code.

.NET Core 'provided' a tool named R2RDump for inspecting those data. The tool can be configured to dump all the information to stdout. The information includes CPU native instructions, information to report to GC, how to unwind the stack, how the debugger understands the native code, and more.

Core Proposal

I propose we can display that information in ILSpy. This can be viewed in the natural ILSpy way.

Benefits

1. Make the information available:

The R2RDump tool is not available as part of .NET Core install, as a result, people probably do not know this tool exists.

2. Make the information more accessible:

Working with a giant text file can be inconvenient. The tree structure provided by the ILSpy makes the information more accessible.

3. Make the information more understandable:

I have ways to make the information more understandable by weaving it with the code. For example, in dotnet/diagnostics#452, @neeraj9 and I made the line mapping information more understandable by weaving it with the disassembly. We can do the same here.

4. Make the information more interactive:

I noticed that in ILSpy, I could make links. The links could potentially make navigating the disassembly easier.

Progress

I have started prototyping the idea, and I am able to display some raw disassembly with ILSpy. The prototype code is available in my fork using private bits from my refactoring to make the information accessible outside of the R2RDump tool. I also used the iced disassembler by @0xd4d.

Here is what I see in my prototype:

This is very raw right now and we can certainly do better than that.

Next steps

• Getting an agreement with the ILSpy owner whether or not we wanted this feature.
• Define the feature in more detail and define the plan to work on it.

I think it is a great opportunity for us to collaborate, and I am looking forward to it.

@siegfriedpammer, @dgrunwald

[christophwille]

We will be discussing this internally later this week; however, I have a few up front questions:

• Do you propose extending icsharpcode.decompiler.dll or "only" ilspy.exe (commits in your repo suggest the latter)? (Why: the NuGet is eg used by Roslyn and they might not like dragging in tons of new assemblies)
• Do you have a R2RDump file for us (from a public sample). I for one haven't seen any of those dumps before.
• How much "decompilation" vs "dissassembly" would there be in a R2R PE image? Again, personally never played with R2R, don't know how much if any IL is still in there.

[cshung]

Thanks @christophwille for your prompt response.

• I think changing ilspy.exe is good enough. We might even consider to implement it as a plugin. The initial prototype was done for convenience. In fact, it is great that you told me this upfront, your expertise in ILSpy is greatly appreciated.

• To clarify a bit, R2RDump is a tool (implemented in managed code, targetting .NET Core 3.0), it is not a file. The tool can create a text output, in which one could call that a R2RDump file. Attached below shows the disassembly of a single method in System.Private.CoreLib.dll produced by the tool.

...
Boolean Interop+Kernel32.GetVersionExW(ref Interop+Kernel32+OSVERSIONINFOEX)
Handle: 0x0600002B
Rid: 43
EntryPointRuntimeFunctionId: 43
Number of RuntimeFunctions: 1

Boolean Interop+Kernel32.GetVersionExW(ref Interop+Kernel32+OSVERSIONINFOEX)
Id: 43
StartAddress: 0x00399B70
Size: 140 bytes
UnwindRVA: 0x00736FA8
Version:            1
Flags:              0x03 EHANDLER UHANDLER
SizeOfProlog:       0x0013
CountOfUnwindCodes: 10
FrameRegister:      RAX
FrameOffset:        0x0
PersonalityRVA:     0x257B1
UnwindCode[0]: CodeOffset 0x0013 FrameOffset 0x0113 NextOffset 0x152 Op 0 -
UnwindCode[1]: CodeOffset 0x0013 FrameOffset 0x0013 NextOffset 0x-1 Op Scaled small
UnwindCode[2]: CodeOffset 0x000C FrameOffset 0x300C NextOffset 0x-1 Op RBX(3)
UnwindCode[3]: CodeOffset 0x000B FrameOffset 0x600B NextOffset 0x-1 Op RSI(6)
UnwindCode[4]: CodeOffset 0x000A FrameOffset 0x700A NextOffset 0x-1 Op RDI(7)
UnwindCode[5]: CodeOffset 0x0009 FrameOffset 0xC009 NextOffset 0x-1 Op R12(12)
UnwindCode[6]: CodeOffset 0x0007 FrameOffset 0xD007 NextOffset 0x-1 Op R13(13)
UnwindCode[7]: CodeOffset 0x0005 FrameOffset 0xE005 NextOffset 0x-1 Op R14(14)
UnwindCode[8]: CodeOffset 0x0003 FrameOffset 0xF003 NextOffset 0x-1 Op R15(15)
UnwindCode[9]: CodeOffset 0x0001 FrameOffset 0x5001 NextOffset 0x-1 Op RBP(5)

GC info:
    Version:                           2
    ReturnKind:                        RT_Scalar
    ValidRangeStart:                   0x0000
    ValidRangeEnd:                     0x0000
    SecurityObjectStackSlot:           0xFFFFFFFF
    GSCookieStackSlot:                 0xFFFFFFFF
    PSPSymStackSlot:                   0xFFFFFFFF
    GenericsInstContextStackSlot:      0xFFFFFFFF
    StackBaseRegister:                 4294967295
    SizeOfENCPreservedArea:            0xFFFFFFFF
    ReversePInvokeFrameStackSlot:      0xFFFFFFFF
    SizeOfStackOutgoingAndScratchArea: 0x0000
    NumSafePoints:                     5
    NumInterruptibleRanges:            0
    SafePointOffsets: 5
        Index:  0; Value: 0x0035
        Live slots:                     RegisterNumber: 6
                        Flags: GC_SLOT_INTERIOR

        Index:  1; Value: 0x0054
        Live slots:
        Index:  2; Value: 0x005A
        Live slots:
        Index:  3; Value: 0x0069
        Live slots:
        Index:  4; Value: 0x006F
        Live slots:
    InterruptibleRanges: 0
    SlotTable:
        NumRegisters:  1
        NumStackSlots: 0
        NumUntracked:  2
        NumSlots:      3
        GcSlots:       3
            Index:  0; RegisterNumber:  6; Flags: GC_SLOT_INTERIOR
            Index:  1; RegisterNumber: -1; Flags: GC_SLOT_UNTRACKED
            Index:  2; RegisterNumber: -1; Flags: GC_SLOT_UNTRACKED

  399b70: 55                    push rbp
                                UWOP_PUSH_NONVOL RBP(5)
  399b71: 41 57                 push r15
                                UWOP_PUSH_NONVOL R15(15)
  399b73: 41 56                 push r14
                                UWOP_PUSH_NONVOL R14(14)
  399b75: 41 55                 push r13
                                UWOP_PUSH_NONVOL R13(13)
  399b77: 41 54                 push r12
                                UWOP_PUSH_NONVOL R12(12)
  399b79: 57                    push rdi
                                UWOP_PUSH_NONVOL RDI(7)
  399b7a: 56                    push rsi
                                UWOP_PUSH_NONVOL RSI(6)
  399b7b: 53                    push rbx
                                UWOP_PUSH_NONVOL RBX(3)
  399b7c: 48 81 ec 98 00 00 00  sub rsp, 152
                                UWOP_PUSH_NONVOL Scaled small
  399b83: 48 8d ac 24 d0 00 00 00  lea rbp, [rsp + 208]
  399b8b: 4c 89 55 b0           mov qword ptr [rbp - 80], r10
  399b8f: 33 c0                 xor eax, eax
  399b91: 48 89 45 c0           mov qword ptr [rbp - 64], rax
  399b95: 48 89 45 b8           mov qword ptr [rbp - 72], rax
  399b99: 48 8b f1              mov rsi, rcx
  399b9c: 48 89 75 c0           mov qword ptr [rbp - 64], rsi
  399ba0: ff 15 72 2e c7 ff     call qword ptr [0xca18]       // Void System.StubHelpers.StubHelpers.ClearLastError() (METHOD_ENTRY)
  399ba6: 48 8b 4d b0           mov rcx, qword ptr [rbp - 80]
  399baa: 48 8b 49 20           mov rcx, qword ptr [rcx + 32]
  399bae: 48 8b 39              mov rdi, qword ptr [rcx]
  399bb1: 48 8b ce              mov rcx, rsi
  399bb4: 48 89 4d b8           mov qword ptr [rbp - 72], rcx
  399bb8: 48 8d 8d 58 ff ff ff  lea rcx, [rbp - 168]
  399bbf: ff 15 83 74 c6 ff     call qword ptr [0x1048]       // PINVOKE_BEGIN (HELPER)
  399bc5: 48 8b 4d b8           mov rcx, qword ptr [rbp - 72]
  399bc9: ff d7                 call rdi
  399bcb: 8b f0                 mov esi, eax
  399bcd: 48 8d 8d 58 ff ff ff  lea rcx, [rbp - 168]
  399bd4: ff 15 76 74 c6 ff     call qword ptr [0x1050]       // PINVOKE_END (HELPER)
  399bda: ff 15 40 2e c7 ff     call qword ptr [0xca20]       // Void System.StubHelpers.StubHelpers.SetLastError() (METHOD_ENTRY)
  399be0: 85 f6                 test esi, esi
  399be2: 0f 95 c0              setne al
  399be5: 0f b6 c0              movzx eax, al
  399be8: 0f b6 c0              movzx eax, al
  399beb: 48 8d 65 c8           lea rsp, [rbp - 56]
  399bef: 5b                    pop rbx
  399bf0: 5e                    pop rsi
  399bf1: 5f                    pop rdi
  399bf2: 41 5c                 pop r12
  399bf4: 41 5d                 pop r13
  399bf6: 41 5e                 pop r14
  399bf8: 41 5f                 pop r15
  399bfa: 5d                    pop rbp
  399bfb: c3                    ret
...

(The full output has 158,221,724 bytes describing 27968 methods, that is 5657.24 bytes per method)

• All the IL (and perhaps some additional IL due to generated PInvoke Stub) stays in the binary using the same CLI format, in fact, C# decompilation just works on ReadyToRun images.

[christophwille]

Thanks for your clarifications. Having this functionality in-box (either in ilspy.csproj or an addin in our repo) definitely is interesting - we have to discuss the two options (ie maybe your code can make use of objects that we already have, like an SRM instance or something)

[cshung]

Thanks for your clarifications. Having this functionality in-box (either in ilspy.csproj or an addin in our repo) definitely is interesting

Thanks for the confirmation - can I assume we reached agreement on the first check box?

• Getting an agreement with the ILSpy owner whether or not we wanted this feature.

It would be great if you can check it on the first issue to confirm that is the case. 🥇

we have to discuss the two options

I am a little confuse about the 'two' options here ... what do you mean?

(ie maybe your code can make use of objects that we already have, like an SRM instance or something)

If I understand you correctly, you are probably suggesting having a R2RReader constructor that takes a MetadataReader as input to avoid duplicating the reading and the memory usage. That sounds like a great idea, I can give that a try. In general, ILCompiler.Reflection.ReadyToRun is currently fairly flexible. As long as it still serves its purposes (currently, it is only used to support R2RDump), we can make any reasonable changes to it. My idea is that the library serves the role similar to System.Reflection.Metadata.dll, which offers the raw data, and then we have a layer on top to provide the presentation of it (in this case, the ReadyToRunLanguage class).

Discussing the implementation specific is getting slightly ahead of what I was thinking (which is great by the way 👍). What I was thinking is to create a project plan (which is my second checkbox). Once we have the list of things to do, we can move forward to plan for other resources on it (time/people/other resources?). I wish this can fit into the ILSpy release schedule somehow.

Here is roughly what I think the work items are:

• Design and implement the disassembly enriching, this can include:

1. Weave the unwind opcodes into the disassembly
2. Weave the decompiled C# into the disassembly (something similar to the C# with IL view)
3. Weave the symbolic callee information into the disassembly.
4. Label local access with symbolic information (maybe local names from PDB/portable PDB?)
5. Make them navigable
6. Coloring
7. Supporting other architectures (x86/arm/arm64)
8. Handling generics.
   ...

• Design and implement the Decompile method for non-code nodes (such as the assembly node and field nodes:

1. Header information - such as target architecture - for the assembly node
2. Field information - not sure if we can obtain the assumed field offset, we probably cannot - but maybe we will be able to.

These are just my ideas, the list is just random ideas without a specific order, feel free to modify the list in whatever way you think it makes sense.

Last but not least, if it is not convenient to work on this right now (because of the holidays), we don't have to work on this right now, there is no urgency.

[christophwille]

The two options I was referring to were "include the functionality (a) inside ILSpy or (b) in a separate addin" - that was part of the brief implementation "discussion" about saving cpu/memory/disk access by reusing SRM instances, which obviously might be easier inside ILSpy than from the outside (addin). Which, however, might be undesirable for other reasons - we have a code review call on Friday and we'll talk that through.

[siegfriedpammer]

We have discussed this earlier today and concluded that it would be best to do the following:

1. Let's name it "ILSpy.ReadyToRun"
2. We would like to implement it as separate plugin: ILSpy.ReadyToRun.plugin.dll

• Will be distributed out-of-the-box with ILSpy.exe

3. Add it to the ILSpy repository in ILSpy.sln (please provide a PR)

If I understand you correctly, you are probably suggesting having a R2RReader constructor that takes a MetadataReader as input to avoid duplicating the reading and the memory usage.

Yes, exactly. For every loaded valid assembly, you can retrieve the SRM PEReader and MetadataReader. Inside of ILSpy, you can assume that PEReader.IsEntireImageAvailable and PEReader.HasMetadata are true for every assembly.

For example:

public override ProjectId DecompileAssembly(LoadedAssembly assembly, ITextOutput output, DecompilationOptions options)
{
	PEFile module = assembly.GetPEFileOrNull();
	System.Reflection.Metadata.MetadataReader metadata = module.Metadata;
	System.Reflection.PortableExecutable.PEReader peReader = module.Reader;
}

in case of the other Decompile methods in Language, you can do:

public override void DecompileProperty(IProperty property, ITextOutput output, DecompilationOptions options)
{
	PEFile assembly = property.ParentModule.PEFile;
	...
}

I wish this can fit into the ILSpy release schedule somehow.

We would like to add this feature in smaller batches (multiple PRs), so that we can release newer versions of ILSpy more frequently and also get public feedback on the feature.

Your list of work items looks quite complete to me.

Thank you for your interest in contributing to ILSpy!