ILDASM /linenum support?

[dsyme]

The is either a question or a bug report. Basically does the /linenum flag of ILDASM work with .NET Core?

Context: We use ILDASM in the F# repo from package “Microsoft.NETCore.ILDAsm". However I can’t get the “/linenum” option to workm, e.g. to show the PDB file contents in terms of sequence points. We use this to lock down our debugging experience, which is quite important one way or another. I could dump the sequence points from the compiler but it’s really convenient to have them showing with the IL code.

Repro:

• Compile something with portable symbols
• run ildasm /linenum /text foo.dll

e.g. in F# repo:

ildasm.exe artifacts\bin\FSharp.Core\Debug\netstandard2.0\FSharp.Core.dll /linenum

Expected: output include .line Actual: no .line observed

We've tried lots of variations like embedded symbols etc., we can't find a configuration that works.

cc @vzarytovskii, @brettfo

[JulieLeeMSFT]

@EgorBo PTAL.

[am11]

When ilasm received the support for portable PDB, ildasm was left out https://github.com/dotnet/runtime/pull/37702#issuecomment-653255368. It is more of a feature request than a bug report. 😄

Note that once portable PDB parser is plugged into ildasm, this condition will start to satisfy: https://github.com/dotnet/runtime/blob/abb7df59eb4f8c813c07ddd6f46f94e59604577d/src/coreclr/ildasm/dis.cpp#L1132 in the statement fInsertSourceLines = g_fInsertSourceLines; under if (g_pSymReader) condition, g_fInsertSourceLines is 1 with /linenum or -linenum argument, otherwise 0; but that statement is unreachable because g_pSymReader is always null in ildasm.

[TIHan]

@am11 Thank you for the added context here, it's very helpful.

We should definitely support portable PDBs for this; it would help make F# debug testing a bit easier.

[ivanpovazan]

Hello, I decided to work on this (as I worked on the ilasm support for portable PDB as well :)) as part of the hackathon project. Assigning myself

[mirkomaty]

@ivanpovazan: Is there any progress on this issue? We use ILASM/ILDASM roundtrips for an assembly enhancer with C# (see www.netdataobjects.de). ILDASM doesn't generate .line statements with .Net Standard DLLs. That's really bad, because users can't debug enhanced DLLs.

[ivanpovazan]

@mirkomaty I made some initial progress like reading the document table, but had to switch to some other higher priority issues. I will probably get back to this later in November. If you need assistance earlier, maybe @TIHan or someone from the team, could pick this up sooner.

[mirkomaty]

@ivanpovazan: Thanks a lot for your answer. The problem is not so urgent, because currently I tell my users to use

<DebugType>full</DebugType>

But since .NET Core will be the dominant platform in the future, there is little point in having my users insert that line into their project files all the time.

I'm not able to customize ILDasm myself, so I appreciate you taking the time to do so. ;-) If it happens this year, it is perfect for me. Thanks again.

[ivanpovazan]

Unfortunately, I will not have enough cycles to look further into this in the near future. Will remain at disposal if anyone needs help or has questions around this.

[mirkomaty]

Hello, is there any progress in this area?

I created a simple project with this project file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>disable</Nullable>
      <DebugMode>full</DebugMode>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="ndo.dll" Version="5.0.0" />
  </ItemGroup>

</Project>

I took ILDasm from the package runtime.win-x64.microsoft.netcore.ilasm in the version 8.0.0.0. Disassembling with Dasm with /LINENUM switch doesn't provide any line numbers regardless of the TargetFramework (netstandard 2.0 or net6.0).

EDIT: Same with v. 9.0.0-preview.3.24172.9

ILDasm from the .NET Fx Tools 4.8 does the trick. It seems, as if the full pdb support has been removed in order to replace it with portable pdb support, which never happened. It would help a lot to get the pdb support back as long as portable pdb is not implemented.

[JulieLeeMSFT]

Reassigned to @amanasifkhalid.