About debuginfod

Note:
This documentation has moved to a new home! Please update your bookmarks to the new URL for the up-to-date version of this page.

3 Likes

Maybe link “manually install” to Debug Symbol Packages - Ubuntu Wiki, if that page is still up-to-date.

Can you show an example of debuginfod in action, on the client side?

Also, does each invocation of gdb trigger a download, or are those symbols installed in some cache directory? Or are the actual ddebs installed, as if I followed https://wiki.ubuntu.com/Debug%20Symbol%20Packages and installed them manually?

Good idea, thanks. Link done.

I have expanded the article to better explain these points. Please take a look and let me know what you think. Thanks.

1 Like

I don’t think you need to repeat that.

I didn’t like repeating it, but I also thought it’d be worth mentioning again. Anyway, I’ve removed the paragraph.

Nice!
Other questions that come to mind now, which you can decide if are worth expanding in the docs or not (after all, this is not a tutorial):

  • if the binary is updated (assuming it came from a deb), gdb will me smart enough to download a new set of symbols?
  • will that local cache just keep growing? Any tips on pruning it? Can it be pruned per-package? (i.e., "please remove debuginfod info for package libreoffice only). I’m making a comparison with ddebs, which I can remove individually.
  • can ddebs coexist with the data downloaded by debuginfod? Or should I remove the ddeb lines from sources.list? Is there a fallback ordering of some sort?
  • how tightly is this coupled with deb packaging? Can I use gdb against something I coded and built locally (i.e., hello_world.c), which uses some system libraries, and have gdb download debuginfod data for those system libraries?
1 Like

Thanks for the careful review!

I would like to keep this page simple because it will be the landing page for https://debuginfod.ubuntu.com, but I also understand that there might be other details about the service that would be good to cover.

I think it may be worth having a separate FAQ page that’s not directly part of the Server Guide but is linked from this page, WDYT? Then I can not only go over more details about the service, but also allow the users to ask their questions in a single place.

A FAQ is fine, elsewhere here on Discourse, or even in the Server Guide as another page/section, I wouldn’t mind.

1 Like
  • if the binary is updated, its buildid will change, thus a new debuginfo file would be sought
  • the local cache is aged periodically, so that old unaccessed files are deleted, see [man debuginfod-client-config(7)]
  • by the way, for running locally built binaries that have stripped debuginfo, you could run a personal debuginfod instance whereever the complete unstripped binaries may still be found. Clients can be configured to ask multiple servers. (Servers can also federate to each other, as each server can also be a client.)

There is additional information that can be supplemented here: “debuginfod is indexing ddebs packages from all supported Ubuntu releases. Once a release goes unsupported, we stop indexing ddebs from it and eventually stop serving debug symbols for its packages.”

For example, the situation of ddeb support for different releases and respective suites

  • Suites from regular source: noble, noble-updates, noble-backports, noble-proposed
  • Suites from security source: noble-security
  • Suites from esm-app source: noble-apps-security, noble-apps-updates
  • Suites from esm-infra source: noble-infra-security, noble-infra-updates

I have noticed that the packages from noble-security cannot fetch dbg-sym information.
For instance, in Ubuntu 24.04, openssh-server:

buildid of sshd
c6b029db53c7dd5f3afc7909d5fea694851055bf

gdb sshd output as below:

Reading symbols from sshd...
Reading symhols from /home/user/.cache/debuginfod_client/5b1aebbe7e....
(gdb)

Packages in other suites have corresponding debug info.