How to handle (native) debug info? #267
Comments
|
Here is what an unconditional fix looks like for coreclr: https://gist.github.com/omajid/149e7df053fcaced9a717dee8a67f4f8 |
|
I'm surprised we're stripping symbols in source-build in the first place--packaging for distros is a big reason that flag exists rather than it being hard-coded one way or the other in the repo. Your patch LGTM. @karajas, was that added intentionally in 4b935bc#diff-704fa01630c38f6175a0a426554e9825R5? |
|
I believe at the time, we weren't sure how to handle core-setup symbols. If this is something that the official builds do, I think we should duplicate the same behavior. |
|
Official builds are targeting Microsoft-style symbol servers, which is an area that source-build and the official build need to differ in the short term, IMO. The work to have the official builds strip symbols after the builds are all done seems large to me--similar to the work to move signing to a post-step. |
|
We could also introduce another RepoAPI parameter to control whether or not to strip binaries at build time. I dont know which is easier. |
|
Yeah, all we need is to decide on name (should clarify it by adding However, I think as far as |
|
Okay, then I will keep things unconditional for now. Btw, I looked into all native objects built as part of source-build and only corefx needs additional fixes. Basically a port of dotnet/coreclr#3445 from coreclr to corefx. |
|
/cc @mikeharder in case asp.net core needs similar changes. |
|
/cc @natemcmaster |
|
At the moment, the only native library aspnetcore builds is libuv. See https://github.com/aspnet/libuv-build. cc @moozzyk |
|
The libuv build includes full debugging info for Linux builds. The size of the output is ~460 KB. |
The windows build already includes /Zi /Zl as part of commit 920fd2f (PR #7840). It looks like it was simply missed on Unix. This change also makes the native debug information closer to what CoreCLR does on all platforms. See dotnet/coreclr#3445 for more information. This is also needed for the end-to-end debuginfo generation as part of source-build. See dotnet/source-build#267
When packaging .NET for Linux distributions, the package builders
generally use a different workflow for shipping symbols to users:
1. The package maintainer builds code with the debug flags (such as
`-g`) to generate full native debug info and symbols.
2. Nothing is stripped from build by the package maintainer.
3. The build system (`rpmbuild`, `debuild`) removes the debug
info (or debug symbols) from the code and creates separate
`-debuginfo` or `-debug` packages that contain just the debug
symbols.
4. These debug packages are then distributed along with the normal
packages using the normal Linux distribution mechanisms. This lets
users install the exact set of debug symbols matching their other
package.
To support this workflow in dotnet/runtime, we need to add optional
support for not stripping debug symbols. I used it has follows:
CFLAGS=-g CXXFLAGS=-g ./build.sh --keepnativesymbols true
After this build, the built binaries include all debug symbols.
I can then rely on the distro package build system to identify, strip,
package and ship the debug info/symbols separately.
See dotnet#3781 and
dotnet/source-build#267 for more details on
the background and motivation.
For some related fixes, see:
- dotnet/coreclr#3445
- dotnet/corefx#24979
When packaging .NET for Linux distributions, the package builders
generally use a different workflow for shipping symbols to users:
1. The package maintainer builds code with the debug flags (such as
`-g`) to generate full native debug info and symbols.
2. Nothing is stripped from build by the package maintainer.
3. The build system (`rpmbuild`, `debuild`) removes the debug
info (or debug symbols) from the code and creates separate
`-debuginfo` or `-debug` packages that contain just the debug
symbols.
4. These debug packages are then distributed along with the normal
packages using the normal Linux distribution mechanisms. This lets
users install the exact set of debug symbols matching their other
package.
To support this workflow in dotnet/runtime, we need to add optional
support for not stripping debug symbols. I used it has follows:
CFLAGS=-g CXXFLAGS=-g ./build.sh --keepnativesymbols true
After this build, the built binaries include all debug symbols.
I can then rely on the distro package build system to identify, strip,
package and ship the debug info/symbols separately.
See #3781 and
dotnet/source-build#267 for more details on
the background and motivation.
For some related fixes, see:
- dotnet/coreclr#3445
- dotnet/corefx#24979
) The windows build already includes /Zi /Zl as part of commit 920fd2f (PR dotnet/corefx#7840). It looks like it was simply missed on Unix. This change also makes the native debug information closer to what CoreCLR does on all platforms. See dotnet/coreclr#3445 for more information. This is also needed for the end-to-end debuginfo generation as part of source-build. See dotnet/source-build#267 Commit migrated from dotnet/corefx@efe7652
In the context of packaging for various Linux distributions, the topic of (native) debuginfo comes up.
Here is what many linux distributions do:
-gwith gcc/clang,RelWithDebInfofor cmake)-debuginfofor Fedora/RHEL/CentOS,-dbgsymfor Debian/Ubuntu).Now if users want to just run .NET Core, they install
dotnet. If they want to use the debug symbols, they need to installdotnet-debuginfoordotnet-dbgsym(or the variant used by the distro).Neither source-build nor the current official build accounts for this. These builds just strip out everything that leaves the package build process nothing to work with. For example, see https://github.com/dotnet/core-setup/issues/1607
I would like to "fix" this in source-build. Should I just remove the various invocations to strip debug info? Is there a need to make this conditional depending on the current platform? Or even build type?
The text was updated successfully, but these errors were encountered: