Date: Thu, 02 Jul 2020 13:09:19 -0400
From: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
Subject: Debug symbol compression
To: ~alpine/devel@lists.alpinelinux.org
MIME-Version: 1.0
Message-Id: <1593702164.2nw55qdomr.none@localhost>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
References: <1593702164.2nw55qdomr.none.ref@localhost>

Modern DWARF debugging sections can be compressed with zlib to save=20
storage. This is done using the gcc -gz or objcopy=20
--compress-debug-sections options.

Currently, Alpine does not compress debug sections. I think we should=20
consider doing so.

=3D=3D Benefits =3D=3D

Compressing debug sections saves a lot of installed disk space. For=20
example, I took mesa-dbg (the largest dbg apk currently), ran

    find . -name \*.debug -exec objcopy --compress-debug-sections {} \;

and reduced the installed size from 452M to 181M.

=3D=3D Drawbacks =3D=3D

=3D=3D=3D Compatibility =3D=3D=3D

Some programs may not be compatible with compressed DWARF sections.=20
While gdb and lldb support it just fine, libunwind does not support it=20
until the not-yet-released v1.5. libexecinfo doesn't support compressed=20
DWARF sections, but it doesn't support split debug either, so it's a=20
moot point. It also seems that libexecinfo is broken now anyways: [1].

=3D=3D=3D Speed =3D=3D=3D

Obviously, compressed debug sections take somewhat longer to load. I=20
haven't tested it, but based on my experience using Gentoo, up to a few=20
extra seconds loading very large debug symbol files (e.g. mesa, firefox)=20
can be expected. This probably also applies to applications taking their=20
own backtraces using libunwind, but I'm not sure.

=3D=3D=3D Size =3D=3D=3D

In theory, compressing debug sections should slightly increase APK size.=20
However, in practice, I found this not to be the case. gzip uses a=20
fairly small window, so in fact double-compressing large, highly=20
compressible files can sometimes reduce the size. In this case,=20
musl-dbg tar size (i.e. without apk headers) decreased from 179984559=20
bytes to 177951179 bytes. Smaller dbg apks will likely see a slight=20
increase.

Unfortunately, this reverses completely with zstd. Using zstd -9,=20
compressing debug sections causes the tar size to increase from=20
134414806 to 178504848. This makes sense, because at high levels, zstd=20
compression is much more powerful than gzip. Unfortunately, there seems=20
to be no support for zstd or even LZMA DWARF compression at this time,=20
so unless we implement something like precomp [2], which seems overly=20
complicated for a simple `apk add`, it would increase the resulting apk=20
size.

=3D=3D Conclusions =3D=3D

Overall, I think that once libunwind is bumped to 1.5, we should start=20
compressing debug sections. We shouldn't support old bundled versions of=20
gdb or libunwind, and the installed size benefit is substantial. In my=20
opinion, the speed difference is negligible compared to the size=20
benefits. If we switch to zstd apk format, then that will unfortunately=20
likely need to be reverted.

[1] https://gitlab.alpinelinux.org/alpine/aports/-/issues/10896
[2] https://github.com/schnaader/precomp-cpp