Debug symbols for 2.0.3

[TicoDePano]

The links to download symbols from link
https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.0.3.md
aren't working.

Using Source Link, even at Microsoft Symbols Server some symbols were not loaded.

Is there a problem getting these symbols or I misunderstand something about how to get them?

[Petermarcu]

@leecow do you have to correct links. Also seems to be broken that we're pointing to corefx and coreclr for symbols. The shared framework contains both so the link to download shared framework symbols should be all someone needs.

[richlander]

Looks like this was resolved by #1108

[leecow]

The links are correct but definitely something wrong with the corefx symbols zip - it's only 9k. @Petermarcu are you saying the coreclr zip is the only one needed?

[Petermarcu]

I'm saying that there should only be one zip for the shared runtime and it should contain the symbols from coreclr and corefx. Coreclr and corefx are repos and not something we talk about in the product. Lets keep this issue open and link it to an issue create in core-setup that should be the place where a pdb zip file is being created to match the shared runtime.

[leecow]

cc @dagood who has been generating the zips.

[Petermarcu]

@leecow I think this is the zip we need instead of the other two.

https://dotnetcli.blob.core.windows.net/dotnet/Runtime/release/2.0.0/dotnet-runtime-symbols-latest-win-x64.zip

It needs to be versioned for each release but its the one that corresponds to the shared runtime.

[leecow]

Good news that that's the file we want as -runtime-symbols- files are already getting captured when we produce the stabilized builds (eg https://dotnetcli.blob.core.windows.net/dotnet/Runtime/2.0.3/dotnet-runtime-symbols-2.0.3-win-x64.zip).

The zips which @dagood has been gathering are significantly larger. Is there anything in the delta that is important?

[Petermarcu]

Can you share which zips those are? Are they the coreclr and corefx ones we have links to or are they something else?

[dagood]

Each release, I create a zip for coreclr, corefx, and core-setup. For 2.0.3, the only CoreFX package released was Microsoft.NETCore.Platforms 2.0.1, and I don't go backwards to try to accumulate everything from older 2.0 releases which are still in use. The end result for 2.0.3 is the corefx zip only has the one small Platforms symbol package in it.

The core-setup symbol package zip is available, just not linked on the markdown doc at the moment: https://download.microsoft.com/download/5/C/1/5C190037-632B-443D-842D-39085F02E1E8/core-setup-2.0.3-symbols.zip

Is there anything in the delta that is important?

One difference is that the core-setup symbol package zip contains the nuget package structure overhead and the dll's/so's/dylib's. The symbol zip only has symbol files in a flat format. I think the same symbol files should be in both, though.

[Petermarcu]

So there are really two things. One that is the flat folder matching whats in shared runtime. The other is the pdb's from the packages we ship right? Getting the one with the packages right is more problematic because, as you said, there is a cummulative nature to it.

For now, I think we should just update the links to point to the runtime zips and then for 2.1 get a good plan in place for how packages should make their symbols available.

[dagood]

The Core-Setup packages/symbol packages (specifically Microsoft.NETCore.App) should contain everything in the shared framework, so it accumulates automatically. The issue is that right now, the doc only links to the coreclr and corefx symbol package zips, not core-setup's. The flat folder might be easier to use (I think it might make sense to link to those for that reason), but the contents that matter should be in either one.

[Petermarcu]

What were the next steps here. Do we have other issues tracking getting a symbols for the runtime in one folder/archive?

[Petermarcu]

@dagood is this issue resolved now?

[dagood]

The docs now point to all symbol archive zips that apply to a given servicing release. This can be up to three, depending on which Runtime repos are involved. (For example, Core-Setup wouldn't have anything new if CoreFX serviced packages that aren't in the shared runtime.)

We've talked about the symbol zips mostly in this issue, but symbol indexing to the public MSDL symbol server has also been integrated better into our release steps so it's less likely for there to be gaps in availability there.

I think this is resolved, but it seems like my idea of resolved is different from what you have in mind.

[Petermarcu]

By resolved, I mean, can this issue be closed or is it track outstanding work?