From ee555666567f5cb9ab3f99f5d2f9686dcf8e962a Mon Sep 17 00:00:00 2001 From: Sergio Durigan Junior Date: Sat, 13 May 2023 16:44:09 -0400 Subject: [PATCH] New post about Ubuntu, debuginfod and source code indexing Signed-off-by: Sergio Durigan Junior --- content-org/all-posts.org | 87 +++++++++++++++++- .../ubuntu-debuginfod-source-code-indexing.md | 92 +++++++++++++++++++ 2 files changed, 178 insertions(+), 1 deletion(-) create mode 100644 content/posts/ubuntu-debuginfod-source-code-indexing.md diff --git a/content-org/all-posts.org b/content-org/all-posts.org index fbda71e..0322f00 100644 --- a/content-org/all-posts.org +++ b/content-org/all-posts.org @@ -1,11 +1,96 @@ #+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: CLOSED: [2023-04-20 Thu 21:38] :PROPERTIES: :EXPORT_FILE_NAME: novo-blog-novos-links :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]]. 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 diff --git a/content/posts/ubuntu-debuginfod-source-code-indexing.md b/content/posts/ubuntu-debuginfod-source-code-indexing.md new file mode 100644 index 0000000..15b76eb --- /dev/null +++ b/content/posts/ubuntu-debuginfod-source-code-indexing.md @@ -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).