blog/content/posts/ubuntu-debuginfod-source-code-indexing.md

+++
title = "Ubuntu debuginfod and source code indexing"
author = ["Sergio Durigan Junior"]
date = 2023-05-13T16:43:00-04:00
tags = ["english", "ubuntu", "debuginfod", "debian", "free", "software", "gdb"]
draft = false
+++

You might remember that in my [last post](/posts/debuginfod-is-coming-to-ubuntu/) about the [Ubuntu debuginfod
service](https://debuginfod.ubuntu.com) I talked about wanting to extend it and make it index and
serve source code from packages.  I'm excited to announce that this is
now a reality since the Ubuntu Lunar (23.04) release.

The feature should work for a lot of packages from the archive, but
not all of them.  Keep reading to better understand why.


## The problem {#the-problem}

While debugging a package in Ubuntu, one of the first steps you need
to take is to install its source code.  There are some problems with
this:

-   `apt-get source` required `dpkg-dev` to be installed, which ends up
    pulling in a lot of other dependencies.
-   GDB needs to be taught how to find the source code for the package
    being debugged.  This can usually be done by using the `dir`
    command, but finding the proper path to be is usually not trivial,
    and you find yourself having to use more "complex" commands like
    `set substitute-path`, for example.
-   You have to make sure that the version of the source package is the
    same as the version of the binary package(s) you want to debug.
-   If you want to debug the libraries that the package links against,
    you will face the same problems described above for each library.

So yeah, not a trivial/pleasant task after all.


## The solution... {#the-solution-dot-dot-dot}

Debuginfod can index source code as well as debug symbols.  It is
smart enough to keep a relationship between the source package and the
corresponding binary's Build-ID, which is what GDB will use when
making a request for a specific source file.  This means that, just
like what happens for debug symbol files, the user does not need to
keep track of the source package version.

While indexing source code, debuginfod will also maintain a record of
the relative pathname of each source file.  No more fiddling with
paths inside the debugger to get things working properly.

Last, but not least, if there's a need for a library source file and
if it's indexed by debuginfod, then it will get downloaded
automatically as well.


## ... but not a perfect one {#dot-dot-dot-but-not-a-perfect-one}

In order to make debuginfod happy when indexing source files, I had to
patch `dpkg` and make it always use `-fdebug-prefix-map` when
compiling stuff.  This GCC option is used to remap pathnames inside
the DWARF, which is needed because in Debian/Ubuntu we build our
packages inside chroots and the build directories end up containing a
bunch of random cruft (like `/build/ayusd-ASDSEA/something/here`).  So
we need to make sure the path prefix (the `/build/ayusd-ASDSEA` part)
is uniform across all packages, and that's where `-fdebug-prefix-map`
helps.

This means that the package **must** honour `dpkg-buildflags` during its
build process, otherwise the magic flag won't be passed and your DWARF
will end up with bogus paths.  This should not be a big problem,
because most of our packages do honour `dpkg-buildflags`, and those
who don't should be fixed anyway.


## ... especially if you're using LTO {#dot-dot-dot-especially-if-you-re-using-lto}

Ubuntu enables [LTO](https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html) by default, and unfortunately we are affected by an
[annoying (and complex) bug](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805) that results in those bogus pathnames not
being properly remapped.  The bug doesn't affect all packages, but if
you see GDB having trouble finding a source file whose full path
starts without `/usr/src/...`, that is a good indication that you're
being affected by this bug.  Hopefully we should see some progress in
the following weeks.


## Your feedback is important to us {#your-feedback-is-important-to-us}

If you have any comments, or if you found something strange that looks
like a bug in the service, please reach out.  You can either send an
email to my [public inbox](https://lists.sr.ht/~sergiodj/public-inbox) (see below) or file a bug against the
[ubuntu-debuginfod project on Launchpad](https://bugs.launchpad.net/ubuntu-debuginfod).