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

[Neven Sajko]

> 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.

Golang (and libbacktrace) use DWARF for backtraces at runtime.

> 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...

I would of course prefer split debugging symbols to no symbols at all.

> 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?

Sorry, I did not mean to argue that absolutely all executables must be
installed with debugging symbols. The ideal situation I am imagining
is that if a packager thinks the debugging symbols would be too much
for some executable in the package, she simply disables them and
enables stripping for the whole package. But most executables are
small and stripping their debugging symbols does not gain much.

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

I was actually referring to the fact that this feature was not
available before because of libalpm limitations (I think that required
hooks or somehing, and was only added recently?). Anyway, I am not
saying this is some great issue, but it certainly somewhat increases
complexity of some Arch projects. But maybe that complexity is good if
it is not exclusively needed for this usecase, thus on further thought
I probably should have done more research before raising this
particular point.

> 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.

I assumed libbacktrace could not do that because of constraints on
memory allocation (whether on stack or on heap) or reentrancy, but
apparently it has that functionality since 2017. Oops.

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

Depending on an arbitrary file determined by a path is complicated,
there are all kinds of concerns, like async-signal-safety (one has to
use open instead of fopen), getting the file before somebody
overwrites it or moves it (or just changes a symlink) ...

> 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.

Well this is certainly *complicated*. But it is warranted because of
the great size difference, most packages don't need this and could
include debugging symbols, I think.

To reiterate, I certainly think that split debugging symbols in split
packages in official repos would be an improvement; but I would like
to know why are more packages built with included debugging symbols.
Do you think that, eg., all packages in "core" being built with
debugging symbols would be OK? Maybe it would be OK if just function
names were included, without source file line info?

Sidenote: Do you know why are split debug packages not yet available?

Regards,
Neven Sajko