Investigate dotnet-symbol binary mismatch

After installing Linux x64 3.0.100 release, I tried to download the symbols for the runtime.

$ dotnet --list-runtimes
Microsoft.AspNetCore.All 2.1.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.13 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.7 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

$ dotnet-symbol --recurse-subdirectories /usr/share/dotnet/shared/Microsoft.NETCore.App/3.0.0/libcoreclr.so -o 3.0.0-symbols
Downloading from http://msdl.microsoft.com/download/symbols/
Writing files to 3.0.0-symbols
Writing: 3.0.0-symbols/libcoreclr.so
Writing: 3.0.0-symbols/libcoreclr.so.dbg
Writing: 3.0.0-symbols/libmscordaccore.so
Writing: 3.0.0-symbols/libmscordbi.so
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/libsos.so/elf-buildid-coreclr-b4c030672d8bb8cffdae6ebfac0717763f6677f8/libsos.so'
ERROR: HttpSymbolStore: 404 Not Found 'http://msdl.microsoft.com/download/symbols/sos.netcore.dll/elf-buildid-coreclr-b4c030672d8bb8cffdae6ebfac0717763f6677f8/sos.netcore.dll'

$ md5sum 3.0.0-symbols/libcoreclr.so* /usr/share/dotnet/shared/Microsoft.NETCore.App/3.0.0/libcoreclr.so
b47b275c67a0669c16bdc4f877ef999a  3.0.0-symbols/libcoreclr.so
f3476f8f604902fc320ee7e43ea55529  3.0.0-symbols/libcoreclr.so.dbg
b31e674bd71a6a552c7effd2d7ba3838  /usr/share/dotnet/shared/Microsoft.NETCore.App/3.0.0/libcoreclr.so

As shown the versions do not match.

The downloaded 3.0.0-symbols/libcoreclr.so is missing debug info, but does have a symtab

[dagood]

Ah… forgot about this. The Debian package has it stripped while the tarball and the symbol package have it unstripped. (Edit: Rather, “not all the way stripped”. file reports unstripped but some stripping has been done.)

Since stripping happens after the build, this doesn’t affect build ID:

#> for x in *; do du $x ; sha256sum $x | cut '-d ' -f1 ; file $x | cut -d, -f5-6; echo; done
7332    libcoreclr_debpkg.so
43a52aed991d928db33d3c2a22ba9d8b10d154cac07a1ee88c8c55864c54cf58
 BuildID[sha1]=b4c030672d8bb8cffdae6ebfac0717763f6677f8, stripped

8960    libcoreclr_sympkg.so
00dc11b4ab45831ef1648e3d183918df77ef28b234e907c921d5dbb0a821e8ca
 BuildID[sha1]=b4c030672d8bb8cffdae6ebfac0717763f6677f8, not stripped

8960    libcoreclr_zip.so
00dc11b4ab45831ef1648e3d183918df77ef28b234e907c921d5dbb0a821e8ca
 BuildID[sha1]=b4c030672d8bb8cffdae6ebfac0717763f6677f8, not stripped

CoreCLR isn’t stripping it “all the way”, and the Deb package tool is doing the rest at packaging time. Stripping is entirely handled by the Deb/RPM packaging process for traditional Linux builds, which would explain why it does this by default.

https://github.com/dotnet/core-setup/issues/1607 tracks normalizing this. (https://github.com/dotnet/core-setup/issues/8356 tracks embracing debuginfo/dbgpkg to fit in with the normal Linux ecosystem.)

This means I don’t think we’ll have any issues with mismatching bits here, since they’re the same build for sure and all that’s different is how far they’re stripped. 😄

[dagood]

It would also be good to know how you acquired .NET Core for that machine in case there’s something weird going on for a specific channel.