Implement support for Embedded Portable PDB

[tmat]

Implements #12390 and #12753

[tmat]

@dotnet/roslyn-compiler Please review.

[tmat]

@jaredpar @marek-safar FYI

[tmat]

@jaredpar I have not added /debug:windows. I thought about it and concluded that it'd be mostly adding noise -- I don't think anyone would really use it. If you feel strong about it I can certainly follow up and add it. We could also wait for customers to ask for it.

[jaredpar]

I've gone back and forth on this. At this point I think we're fine not implementing /debug:windows now. We can keep it in our back pocket should a scenario come along where this is needed.

[jaredpar]

Can we add a test which validates that on Linux we are choosing the correct PDB format? Either use ConditionalFact or run on both OS and verify that on Linux we use Portable, and Windows PDB

[jaredpar]

Ah I see where you added those.

[tmat]

This test does validate that on Linux/Mac we use Portable PDB and otherwise Windows PDB. ConditionalFact does the same check of PathUtilities.IsUnixLikePlatform value as the line below.

[marek-safar]

I am not sure this is the only check we need. I didn't test this but I believe it'll still not work because COM support in Mono on Windows is not really working.

[tmat]

That's unfortunate. #12753 states that /debug:full is OS specific, but not runtime specific. Does Mono not support COM at all? The interop we need is very simple (no COM registration needed). We P/Invoke native dll that directly returns COM object, which we then call methods on.

[tmat]

@jaredpar Keeping it in a back pocket sounds good to me.

[jaredpar]

CC @dotnet/roslyn-compiler now that this is out for official review.

👍 from me.

[tmat]

@dotnet/roslyn-compiler Ping.

[jcouv]

LGTM
Sorry I missed the design presentation on the topic, but what tool will consume the embedded PDB?

[tmat]

All the tools that consume standalone portable PDBs - the debugger, the CLR stack trace library, dotnet cli test tool, etc.