[arch-general] Why are Archlinux packages stripped of (debugging) symbols?

[Eli Schwartz]

On 1/21/20 3:21 PM, Neven Sajko via arch-general wrote:
> Hello,
> 
> Why is it that makepkg strips symbols by default, 

Because Arch Linux's default vendor options for makepkg.conf include the
optional strip option.

> and many packagers
> even make extra effort to get packages stripped; instead of building
> with "-g"? 

Packagers do not go to extra effort for this. makepkg provides this as a
tuneable, and any PKGBUILD is supposed to build with debug symbols when
the "debug" makepkg.conf configuration option is set; if it does not,
then the PKGBUILD has a bug that should be fixed.

> Even Go software, which by Go's design makes use of
> debugging symbols at run time had been stripped as far as I remember
> (although it seems that has changed, thankfully).

There is no "even", here. The golang programming language is not
*atypical*, it should not receive abnormal treatment.

I'm not sure what you men by "design makes use of debugging symbols at
runtime". They're debug symbols, not runtime logic symbols.

> It is quite nice to have debugging symbols in executables for learning
> and entertainment purposes (seriously, try Ghidra or radare2 once),
> and they are, of course, indispensable when bad luck strikes and one
> actually has to debug.

It is very nice indeed! Splitdebug symbols work fine in gdb, and I
believe in radare2 as well: https://github.com/radareorg/radare2/issues/5758

Of course, archlinux doesn't really provide splitdebug packages by
default, so you cannot generally use them unless you're using your own
packages...

> And there do not seem to be any significant downsides to extra
> symbols, it just means more permanent storage and bandwidth used.
> Especially in view of Arch's existing packaging practice patterns,
> like no "-dev" or "-doc" split packages.

Headers and such are distributed along with the main package because by
definition, they are needed as a core part of the project. Anyone who
wants to build reverse dependencies needs them, the *only* people who
don't need development headers are the people who never build packages
themselves. There's a simple solution for such people: pacman.conf
supports "NoExtract = usr/include/"

Also, "NoExtract = usr/share/doc/" if you do not want the help
documentation which many end users do in fact need.

Debug symbols, on the other hand, are *always* unnecessary unless you
are debugging. Moreover, they tend to result in dramatically increased
package size. Headers are tiny, and docs often are (but we have lint
checkers to warn us if abnormal packages contain mostly docs, and there
are several packages that do indeed split out *-docs, so this is not an
absolute!)

Have you tried building, say, a web browser with debugging symbols?

> I know some developers have some degree of desire for split packages
> with stripped symbols in separate files, but that would indeed be
> inconsistent with the lack of "-dev" or "-doc" packages. More
> importantly, splitting symbols from executable files is most of the
> time a harmful complication: it makes packaging more complicated,

No it does not, makepkg handles this transparently with absolutely no
effort on the part of the maintainer.

In fact, makepkg can programmatically split out debug packages using
trivial logic when it *cannot* do so for development files (which
include more than headers) or documentation (which is sort of kind of
standard except not really), which may well be a contributing factor to
why makepkg supports it at all. ;)

> it
> makes using the separated symbols by humans more complicated, and it
> makes using the debugging symbols from the program they belong to
> harder (ref. Ian Lance Taylor's libbacktrace, which does not work with
> symbols in a separate file, very possibly for reasons fundamental to
> libbacktrace's purpose).

Perhaps libbacktrace should work more like gdb then? It works fine with
gdb, and the ELF metadata has .gnu_debuglink for this exact purpose --
it's fundamental to binutils, see the objcopy manpage for example.

You're saying it's "harder and more complicated" to use detached debug
symbols, but I'm really not seeing it.

> To conclude: besides arguing for debugging symbols to be installed as
> part of executable files, I am honestly asking what are the reasons
> for the apparent aversion towards them in Arch's (and wider) culture
> (because I am curious about that).

They're *huge*, and the standard gdb, when used to execute a program or
to inspect a coredump file, can seamlessly merge the detached debug data
and display enhanced debug info. This works even when you only install
the split -debug package using pacman, *after* the program crashes. The
coredump contains all the info you need.

Programs like firefox have extensive upstream tooling for telemetry,
whereby heavily stripped programs are distributed to end users, and if
the program crashes it can send the backtrace to Mozilla.org; this
backtrace is then merged with the debug info which is on Mozilla's
servers, to produce meaningful output. Users don't have to suffer huge
downloads.

(Mozilla's symbol server can also be used with a trivial gdb script to
let gdb download the debug info on-demand, if you're debugging firefox.)

The Arch maintainer for firefox actually does exactly this -- our
firefox package is stripped, but the symbols are uploaded to Mozilla
right after makepkg completes.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20200121/cf63cae1/attachment.sig>