Debian Packages Strip Symbols from Shared Object Files

[brianrob]

The process of producing the .deb package files strips symbols out of the .so files. However, we explicitly include function-level symbols in native binaries for use during performance tracing. tar.gz files are unaffected.

Steps to reproduce

1. Install the .deb files for the shared framework for any of the Ubuntu distros either directly or via apt-get.
2. Run nm </path/to/libcoreclr.so>

Expected behavior

Function-level symbols are displayed.

Actual behavior

No symbols are displayed.

Environment data

[gkhanna79]

@chcosta Will this be addressed as part of your symbol packaging work?

CC @ericstj @noahfalk

[chcosta]

This is not directly related to the symbol packaging work I'm doing. @dagood has more experience with the symbol stripping stuff.

[dagood]

As written, this has more to do with how deb-tool works. That kind of step is where symbol stripping is commonly done in Linux package manager flows (so I hear). I don't know where deb-tool comes from. It seems unrelated to packaging work to me, unless the root cause is how Core-Setup gets CoreCLR bits rather than deb-tool like the description says.

[omajid]

I am from Fedora land, where a similar problem would happen, I suppose. From what I understand, the packaging tool, during the package build process, goes over all binaries and strips them. The stripped binaries are put into a separate package (-dbgsym for Debian, -debuginfo for Fedora).

See AutomaticDebugPackages for how debian packages get stripped during build.

The debian announcement lists a few options to disable the stripping during package build.

[brianrob]

My understanding matches that of @omajid. Likely we just need to disable the stripping when producing packages.

[omajid]

A tangential question: is there some way to automatically verify that symbols needed for performance testing are available?

[brianrob]

Yes, you could do something like nm libcoreclr.so and make sure that the result is not "no symbols".

[brianrob]

Or, you could also take the output of nm before and after the production of the package and diff them.

[omajid]

Thanks, those are good suggestions.

That said, is there some way to verify the functionality itself? What I mean is that the format for debugging symbols seems to be evolving. I know that (some versions of) lldb have trouble reading debugging symbols processed by some versions of rpmbuild. Is there a way to verify that the symbols present are sufficient for the performance tracing implementation in .NET Core to work?

[goldshtn]

I think it would be perfectly fine to provide a separate debuginfo package and put full symbols in it. This makes installation faster and smaller, and most users and production deployments won't need the debuginfo anyway. I realize it might complicate things on your end a bit, but that's what most packages use. Even fundamentals like libc would usually have minimal symbols embedded and then a debuginfo package with full symbols.

@omajid Performance tracing actually works just fine without symbols. You simply don't have symbols on your call stacks for libcoreclr.so and other native modules. It is not critical for performance tracing user code, although is of course very nice to have. There is an even bigger problem around tracing crossgen'd symbols, which I brought up with Brian on a DL.

[omajid]

I think it would be perfectly fine to provide a separate debuginfo package and put full symbols in it

This is what we are doing in Fedora [1]. There's a .NET Core package (dotnetcore) and a debug symbols package (dotnetcore-debuginfo). If debug symbols aren't required for general functionality, I suggest that the debian packages follow the same format. But see also https://github.com/dotnet/core-setup/issues/1599 where packaging names and other issues are being discussed.

[danmoseley]

Assigning to @rakeshsinghranchi per @gkhanna79
@rakeshsinghranchi please let us k now if this will not be resolved by 5/10 ZBB cutoff for 2.0.