|
Size: 2388
Comment: Wording
|
Size: 4595
Comment: Expand on what distros are supported
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
{{{#!wiki caution THIS SERVICE IS NOT FUNCTIONAL YET! THIS PAGE IS A PLACEHOLDER FOR IT! }}} |
|
| Line 16: | Line 9: |
| As of version '''FIXME''', {{{libdebuginfod}}} (part of the {{{elfutils}}} package) will automatically install a file named {{{/etc/profile.d/debuginfod.sh}}} which contains the proper configuration to make your debugging tools work with debuginfod (assuming that they have support for it). | As of version '''TBD''', {{{libdebuginfod}}} (part of the {{{elfutils}}} package) will automatically install a file named {{{/etc/profile.d/debuginfod.sh}}} which contains the proper configuration to make your debugging tools work with debuginfod (assuming that they have support for it). |
| Line 18: | Line 11: |
| If you cannot install this version of {{{libdebuginfod}}}, don't despair! All you have to do is make sure that the following variable is properly set in your environment (usually by editing your {{{~/.bashrc}}}, if you're using Bash): | If you cannot install this version of {{{libdebuginfod}}}, don't despair! All you have to do is make sure that the following environment variable is properly set in your shell (usually by editing your {{{~/.bashrc}}}, if you're using Bash): |
| Line 32: | Line 25: |
| There is an official list in the [[https://sourceware.org/elfutils/Debuginfod.html|project page]]. In Debian sid/buster, {{{GDB}}}, {{{elfutils}}} and {{{binutils}}} all have support for debuginfod. For bullseye, you might need to resort to [[Backports]]. | There is an official list in the [[https://sourceware.org/elfutils/Debuginfod.html|project page]]. In Debian sid/bullseye, {{{GDB}}}, {{{elfutils}}} and {{{binutils}}} all have support for debuginfod. For buster, you might need to resort to [[Backports]]. This may work: {{{ # echo 'deb http://deb.debian.org/debian buster-backports main' > /etc/apt/sources.list.d/backports.list # apt update # apt install -t buster-backports debuginfod elfutils }}} |
| Line 38: | Line 38: |
| * sid (unstable) | * unstable |
| Line 40: | Line 40: |
| * testing-proposed-updates | |
| Line 41: | Line 42: |
| * stable-backports * proposed-updates * experimental The service syncs with both the {{{debian-debug}}} (for {{{-dbgsym}}} files) and the regular {{{debian}}} repository (for the old {{{-dbg}}} files). It only supports the {{{main}}} distribution. |
|
| Line 44: | Line 52: |
| == Who is the resposible for the Debian instance? == | == Where does libdebuginfod store the debuginfo that is downloaded? == According to {{{debuginfod_begin}}}'s manpage: {{{ DEBUGINFOD_CACHE_PATH This environment variable governs the location of the cache where downloaded files are kept. It is cleaned periodically as this program is reexecuted. If XDG_CACHE_HOME is set then $XDG_CACHE_HOME/debuginfod_client is the default location, otherwise $HOME/.cache/debuginfod_client is used. }}} In other words: if {{{DEBUGINFOD_CACHE_PATH}}} is set, then the files are saved in the directory pointed by it. Otherwise, if {{{XDG_CACHE_HOME}}} is set, then files are saved into {{{$XDG_CACHE_HOME/debuginfod_client}}}. Otherwise, the files will be saved into {{{$HOME/.cache/debuginfod_client}}}. == Can I delete the cache directory? == Yes. == The service isn't working! I can't download the source code while debugging a package! == You've just discovered one of the limitations of Debian's debugging experience. To be clear, this is not related to debuginfod: this happens because Debian doesn't package the patched source tree in a consumable way for debugging tools to use. Even before debuginfod, if you tried to debug a package in Debian you would experience the exact same problems. A good example of a distribution that gets this right is Fedora: if you look at how they package debug symbols, you will notice that they generate the equivalent of Debian's {{{dbgsym}}}, but '''also''' create a "debugsource" RPM package that contains the patched source code that was used to build the package. Unfortunately, because of this limitation (which exists since we started generating debuginfo packages in Debian), our debuginfod instance isn't able to index and deliver source code over the network. == Who is resposible for the Debian instance? == |
Debuginfod service
Contents
-
Debuginfod service
- TL;DR: How do I configure my system to use debuginfod?
- What is debuginfod?
- What tools support debuginfod?
- What distributions are supported?
- Where does libdebuginfod store the debuginfo that is downloaded?
- Can I delete the cache directory?
- The service isn't working! I can't download the source code while debugging a package!
- Who is resposible for the Debian instance?
Debian now has a debuginfod server available for its users. Please keep reading this page if you would like to know how to configure your system to use debuginfod.
TL;DR: How do I configure my system to use debuginfod?
As of version TBD, libdebuginfod (part of the elfutils package) will automatically install a file named /etc/profile.d/debuginfod.sh which contains the proper configuration to make your debugging tools work with debuginfod (assuming that they have support for it).
If you cannot install this version of libdebuginfod, don't despair! All you have to do is make sure that the following environment variable is properly set in your shell (usually by editing your ~/.bashrc, if you're using Bash):
export DEBUGINFOD_URLS="https://debuginfod.debian.net"
What is debuginfod?
From the official project page, debuginfod is a client/server [...] that automatically distributes ELF/DWARF/source-code from servers to clients such as debuggers across HTTP.
In other words, debuginfod eliminates the need for users to install debuginfo packages in order to debug programs using GDB, systemtap or other tools. When you configure your system to use a debuginfod server, the debugging tool (which needs to have the support for debuginfod implemented) will automatically download the debug symbols it needs over HTTPS, making the process much more seamless.
What tools support debuginfod?
There is an official list in the project page. In Debian sid/bullseye, GDB, elfutils and binutils all have support for debuginfod.
For buster, you might need to resort to Backports. This may work:
# echo 'deb http://deb.debian.org/debian buster-backports main' > /etc/apt/sources.list.d/backports.list # apt update # apt install -t buster-backports debuginfod elfutils
What distributions are supported?
Currently, we provide debug symbols from the following Debian distributions:
- unstable
- testing
- testing-proposed-updates
- stable
- stable-backports
- proposed-updates
- experimental
The service syncs with both the debian-debug (for -dbgsym files) and the regular debian repository (for the old -dbg files).
It only supports the main distribution.
Eventually, the plan is to support debuginfo files from the snapshot service as well.
Where does libdebuginfod store the debuginfo that is downloaded?
According to debuginfod_begin's manpage:
DEBUGINFOD_CACHE_PATH
This environment variable governs the location of the
cache where downloaded files are kept. It is cleaned
periodically as this program is reexecuted. If
XDG_CACHE_HOME is set then $XDG_CACHE_HOME/debuginfod_client
is the default location, otherwise $HOME/.cache/debuginfod_client
is used. In other words: if DEBUGINFOD_CACHE_PATH is set, then the files are saved in the directory pointed by it. Otherwise, if XDG_CACHE_HOME is set, then files are saved into $XDG_CACHE_HOME/debuginfod_client. Otherwise, the files will be saved into $HOME/.cache/debuginfod_client.
Can I delete the cache directory?
Yes.
The service isn't working! I can't download the source code while debugging a package!
You've just discovered one of the limitations of Debian's debugging experience. To be clear, this is not related to debuginfod: this happens because Debian doesn't package the patched source tree in a consumable way for debugging tools to use. Even before debuginfod, if you tried to debug a package in Debian you would experience the exact same problems.
A good example of a distribution that gets this right is Fedora: if you look at how they package debug symbols, you will notice that they generate the equivalent of Debian's dbgsym, but also create a "debugsource" RPM package that contains the patched source code that was used to build the package.
Unfortunately, because of this limitation (which exists since we started generating debuginfo packages in Debian), our debuginfod instance isn't able to index and deliver source code over the network.