Produce debug information in .NET Core fsi

[auduchinok]

Currently fsi produces full PDBs and it seems it cannot be overriden by console arguments. We'd like it to produce portable PDBs (at least on Mono).
Are there any caveats regarding the generation or reasons to generate full ones?

[nosami]

Does it? I can't even think of a valid reason to produce any kind of debugging symbols (when interpreting)

If you are trying to debug a .fsx script, you can compile instead and can do whatever you like regarding compiler options, e.g. https://github.com/mono/monodevelop/blob/ea63c37090c223c3ac8c7a66c3d106bb24de98c2/main/external/fsharpbinding/MonoDevelop.FSharpBinding/ScriptDebugging.fs#L74

[auduchinok]

@nosami Yes, it was in the context of debugging scripts. Thank you for the link.

Hm. It could be a situation where we detected the PDB type wrongly, I'll double check it with the debugger guys.

[nosami]

@auduchinok Well, that's what I do anyway :) I compile the .fsx to a .exe in a temp folder and then debug that like any other application.

[auduchinok]

Ah, I see. Haven't looked into the code closely yet. :)
It seems it'd possible to debug an in-memory dll with portable PDB on a newer Mono like we do on Windows.

[nosami]

Maybe it is, no idea. I always thought that interpretation and compilation used completely different code paths though, i.e. interpretation uses System.Reflection.Emit vs IL and PDB generation for compilation.

If it is possible, please let me know :)

[nosami]

On Mono, the debugger first checks for the existence of a .pdb file with the same name as the executable and then falls back to .mdb. So fairly certain that any sort of in memory compilation wouldn't work right now.

[dsyme]

@auduchinok There is no debug information at all currently being emitted in .NET Code FSI

For .NET Framework we won't at this stage change what we do

[dsyme]

(Note I've recycled an old issue to cover the need for debug information in .NET Core)

This is related to this issue: dotnet/runtime#28206 (comment)

[KevinRansom]

This is not going to change. The coreclr does not produce debugging information when building and executing scripts. The feature relied on Reflection Emit APIs that do not exist on the coreclr, and on which there is no intention of adding them back into the coreclr.

We may allow script debugging in the future, but it will almost certainly not be dependent upon ref-emit generated assemblies and sequence points.

[dsyme]

We should keep this open as this tracks the missing feature VS support for F# Interactive

From offline conversations with @jkotas it was a question of priority and technicality more than anything else

[cartermp]

I guess, but we should at least tag it appropriately

[dsyme]

See user comment here about how script debugging is killer feature. Was looking for the right issue to link to

https://mobile.twitter.com/snuupo/status/1345053884557963265

[snuup]

Thank you @dsyme

Besides the nice features of F#, having a compiled and scriptable language in the CLR universe was very cool. Then appeared F# script debugging and it is like heaven. Developing difficult algorithms can now be developed incrementally interactively: starting with data analysis in scripting land, an algorithm evolves. I can print intermediate values, graph them and explore the data and the algorithm draft. Being able to debug this algorithm draft inside the script is incredibly helpful, since I do not need to transfer it to the final assembly where it lands after begin completed every time I want to debug. Such transfer is not a simple copy paste, but requires some effort, because the code is in draft stage and might include some development utilities from the script environment that are not available in the final assembly where the algo code lands as it is completed.

So using the REPL as a lab for difficult algorithms and being able to debug draft code right inside it is incredible helpful.

I will dual target my code so I can debug scripts but would be certainly very happy if I would need only Net5 and could do this on all platforms.

[dsyme]

We should solve this by moving to a model where each interaction in FSI emits a different assembly, and we emit each using our standard IL writer with in-memory portable debug symbols.

[snuup]

as of today it is

not possible to debug F# script code
not possible to code called by F# scripts

Is the priority of this issue set such that we get debugging for dotnet core this year? Would love to switch from dotnet48 to 6

[dsyme]

Implemented in #12722

[vzarytovskii]

Closing the issue

[zyzhu]

Great to see debugging on dotnet core FSI coming along. When I tested on 17.1.6 today, I still cannot get the debug working. Is it already in the released version or shall I wait for 17.2?

[vzarytovskii]

Great to see debugging on dotnet core FSI coming along. When I tested on 17.1.6 today, I still cannot get the debug working. Is it already in the released version or shall I wait for 17.2?

It's not in 17.1. It should be in 17.2 though.