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?
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
@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.
@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.
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.
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 :)
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.
@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
(Note I've recycled an old issue to cover the need for debug information in .NET Core)
This is related to this issue: https://github.com/dotnet/runtime/issues/28206#issuecomment-685093288
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.