search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.27k stars 4.73k forks source link

RefEmit does not have the desktop api MarkSequencePoint #28206

Open KevinRansom opened 5 years ago

KevinRansom commented 5 years ago

In FSI we use ILGenerator.MarkSequencePoint to enable debugging of generated code from the in-memory generated assembly.

Will this be added back, and will debugging coreclr code enable it to work correctly once it has been?

// @jkotas, @dsyme, @joshfree, @steveharter

danmoseley commented 5 years ago

The only active ref emit API port issue I know of is https://github.com/dotnet/corefx/issues/12055

danmoseley commented 5 years ago

@jkotas this looks like another case of just expose in contract and add tests - do you believe it's more work than that? Any reason I shouldn't do this?

As we noted elsewhere, there is a lot of Ref.Emit present in S.P.Corelib that is not exposed in contracts, and I believe we planned to make strategic changes only this release.

jkotas commented 5 years ago

Adding symbol/debugging support for reflection emit is a large (likely months) workitem. This is not a simple expose and add tests. The tests added for this would need to be debugger tests.

danmoseley commented 5 years ago

OK. Deferred.

steveharter commented 4 years ago

Linking https://github.com/dotnet/runtime/issues/15704 since that has a discussion on saving IL potentially with debug information.

dsyme commented 4 years ago

Just to say we're really missing this in F# land, as dotnet fsi is not emitting debug symbols. This affects both debugging of scripts and stack traces

snuup commented 3 years ago

F# script debugging, as it is possible with .Net 4.8 is incredible helpful. Such scripts are not just simple bash like admin "scripts" but much more the birthplace of very difficult code, where data analysis grows into algorithms. Being able to debug at this stage is an incredible cool feature.

See also https://github.com/dotnet/fsharp/issues/5457#issuecomment-753359820

jackfoxy commented 3 years ago

First thing I did after installing VS 16.9.1 was enable Use .NET Core Scripting. It took me a while to discover this disables breakpoints in FSI.

zyzhu commented 3 years ago

I second @snuup's comments about importance of debugging in data analysis scripting. Without this feature, scripting F# in Visual Studio will be a far inferior experience compared to debugging R in RStudio, debugging Python in PyCharm or VSCode, or debugging MATLAB.

In addition, it will be a blocking issue for supporting debugging break points in Jupyter Lab through dotnet interactive kernel. https://github.com/dotnet/interactive/issues/320

steveharter commented 2 years ago

Keeping for future; once we have AssemblyBuilder.Save then we should consider.

smoothdeveloper commented 1 year ago

Also suffering from no debug in FSI, for exactly same reasons as @snuup. (https://github.com/dotnet/fsharp/issues/15820)