New post about Ubuntu, debuginfod and source code indexing
Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
This commit is contained in:
parent
0d954e155f
commit
ee55566656
2 changed files with 178 additions and 1 deletions
|
|
@ -1,11 +1,96 @@
|
||||||
#+hugo_base_dir: ../
|
#+hugo_base_dir: ../
|
||||||
|
|
||||||
|
* DONE Ubuntu debuginfod and source code indexing :english:ubuntu:debuginfod:debian:free:software:gdb:
|
||||||
|
CLOSED: [2023-05-13 Sat 16:43]
|
||||||
|
:PROPERTIES:
|
||||||
|
:EXPORT_FILE_NAME: ubuntu-debuginfod-source-code-indexing
|
||||||
|
:END:
|
||||||
|
You might remember that in my [[/posts/debuginfod-is-coming-to-ubuntu/][last post]] about the [[https://debuginfod.ubuntu.com][Ubuntu debuginfod
|
||||||
|
service]] 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
|
||||||
|
|
||||||
|
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...
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
Ubuntu enables [[https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html][LTO]] by default, and unfortunately we are affected by an
|
||||||
|
[[https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805][annoying (and complex) bug]] 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
|
||||||
|
|
||||||
|
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 [[https://lists.sr.ht/~sergiodj/public-inbox][public inbox]] (see below) or file a bug against the
|
||||||
|
[[https://bugs.launchpad.net/ubuntu-debuginfod][ubuntu-debuginfod project on Launchpad]].
|
||||||
|
|
||||||
* DONE Novo blog, novos links :pt_br:portugues:
|
* DONE Novo blog, novos links :pt_br:portugues:
|
||||||
CLOSED: [2023-04-20 Thu 21:38]
|
CLOSED: [2023-04-20 Thu 21:38]
|
||||||
:PROPERTIES:
|
:PROPERTIES:
|
||||||
:EXPORT_FILE_NAME: novo-blog-novos-links
|
:EXPORT_FILE_NAME: novo-blog-novos-links
|
||||||
:END:
|
:END:
|
||||||
Eu sei que não post aqui há algum tempo, mas gostaria de avisar os
|
Eu sei que não posto aqui há algum tempo, mas gostaria de avisar os
|
||||||
meus leitores (hã!?) de que eu troquei a engine do blog pro [[https://gohugo.io][Hugo]].
|
meus leitores (hã!?) de que eu troquei a engine do blog pro [[https://gohugo.io][Hugo]].
|
||||||
Além disso, vocês vão notar que as URLs dos posts mudaram também
|
Além disso, vocês vão notar que as URLs dos posts mudaram também
|
||||||
(elas não têm mais data, agora são só compostas pelo nome do post; mas
|
(elas não têm mais data, agora são só compostas pelo nome do post; mas
|
||||||
|
|
|
||||||
92
content/posts/ubuntu-debuginfod-source-code-indexing.md
Normal file
92
content/posts/ubuntu-debuginfod-source-code-indexing.md
Normal file
|
|
@ -0,0 +1,92 @@
|
||||||
|
+++
|
||||||
|
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).
|
||||||
Loading…
Reference in a new issue