6.5 KiB
DONE Ubuntu debuginfod and source code indexing english ubuntu debuginfod debian free_software gdb
CLOSED: [2023-05-13 Sat 16:43]
You might remember that in my last post about the 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 sourcerequireddpkg-devto 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
dircommand, but finding the proper path to be is usually not trivial, and you find yourself having to use more "complex" commands likeset 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 LTO by default, and unfortunately we are affected by an
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 public inbox (see below) or file a bug against the ubuntu-debuginfod project on Launchpad.
DONE Novo blog, novos links pt_br portugues
CLOSED: [2023-04-20 Thu 21:38]
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 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
veja abaixo), e que também houve uma mudança na tag pt_br:
futuramente eu pretendo parar de postar coisas nela, e vou postar
somente usando a tag portugues. Se você acompanha o RSS/ATOM da tag
pt_br, por favor atualize o link.
As URLs antigas ainda vão funcionar porque elas estão sendo
redirecionadas pro lugar correto (cortesia do mod_rewrite). De
qualquer modo, se você salvou alguma URL de um post antigo, sugiro que
a atualize.
No mais, tudo deve funcionar "como de costume" (TM). Estou postando direto do Emacs (usando ox-hugo), e criei um setup bacana no Sourcehut pra automaticamente publicar os posts assim que eu der o push deles pro git. Hm, isso na verdade seria um bom tópico pra um post…
DONE New blog, new links en_us english
CLOSED: [2023-04-20 Thu 21:26]
I know I haven't posted in a while, but I'd like to let my readers
(who!?) know that I've switched my blog's engine to Hugo. Along with
that change, there are also changes to post URLs (no more dates, only
the post name; but see below) and also a change to the en_us tag:
eventually, I will stop posting things under it and start posting
solely under english. If you're subscribed to the en_us RSS/ATOM
feed, please update it accordingly.
The old URLs should still work because they're being redirected to the
correct path now (thanks, mod_rewrite). Either way, if you have
bookmarked some old post URL I'd suggest that you update it.
Other than that, everything should be "the same" (TM). I'm posting from Emacs (using ox-hugo), and made quite a cool setup with Sourcehut in order to automatically publish posts when I push them to the git repo. Hm, his would actually be a good topic for a post…