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.

These past couple of months I have been working to bring debuginfod to Ubuntu. I thought it would be a good idea to make this post and explain a little bit about what the service is and how I’m planning to deploy it. A quick recap: what’s debuginfod? Here’s a good summary of what debuginfod is: debuginfod is a new-ish project whose purpose is to serve ELF/DWARF/source-code information over HTTP. It is developed under the elfutils umbrella.

Hi there. Long time no write! This last Tuesday, February 23, 2021, I made an announcement at debian-devel-announce about a new service that I configured for Debian: a debuginfod server. This post serves two purposed: pay the promise I made to Jonathan Carter that I would write a blog post about the service, and go into a bit more detail about it. What’s debuginfod? From the announcement above: debuginfod is a new-ish project whose purpose is to serve ELF/DWARF/source-code information over HTTP.

Back in 2016, when life was simpler, a Fedora GDB user reported a bug (or a feature request, depending on how you interpret it) saying that GDB’s gcore command did not respect the COREFILTER_ELF_HEADERS flag, which instructs it to dump memory pages containing ELF headers. As you may or may not remember, I have already written about the broader topic of revamping GDB’s internal corefile dump algorithm; it’s an interesting read and I recommend it if you don’t know how Linux (or GDB) decides which mappings to dump to a corefile.

After spending the last weeks struggling with this, I decided to write a blog post. First, what is “this” that you are talking about? The answer is: Linux kernel’s concept of memory mapping. I found it utterly confused, beyond my expectations, and so I believe that a blog post is the write way to (a) preserve and (b) share this knowledge. So, let’s do it! First things first First, I cannot begin this post without a few acknowledgements and “thank you’s”.

It is really nice to see something you did in a project influence in future features and developments. I always feel happy and proud when I notice such scenarios happening, and this time was no different. Gary Benson, a colleague at Red Hat who works in the GDB team as well, has implemented a way of improving the interface between the linker and the debugger, and one of the things he used to achieve this is the GDB <-> SystemTap integration that I implemented with Tom Tromey 2 years ago.

Nesta última sexta-feira, dia 30/11/2012, estive presente na sétima edição do SoLiSC 2012, em Florianópolis, para apresentar uma palestra introdutória sobre o GDB. Este é um relato sobre minha particição no evento :-). Impressões sobre o evento Foi a primeira vez que fui ao SoLiSC. Já tive vontade de ir em anos anteriores, mas infelizmente sempre havia algo para atrapalhar. No entanto, nesse ano felizmente tudo correu bem, e inclusive tive uma palestra aceita!

Hi everybody :-). I finally got some time to finish this series of posts, and I hope you like the overall result. For those of you who are reading this blog for the first time, you can access the first post here, and the second here. My goal with this third post is to talk a little bit about how you can use the SDT probes with tracepoints inside GDB. Maybe this particular feature will not be so helpful to you, but I recommend reading the post either way.

I tell you this: it is depressing when you realize that you spent more time struggling with blog engines than writing posts on your blog! It’s been a long time since I wrote the first post about this subject, and since then the patches have been accepted upstream, and GDB 7.5 now has official support for userspace SystemTap probes :-). Yay! Well, but enough of cheap talk, let’s get to the business!

Conforme eu havia comentado no post anterior, segue o relato sobre as apresentações que fiz na Semana da Computação da UNESP de Rio Claro. TL;DR: Gostei de ter tido a oportunidade de dar as apresentações, e principalmente de ter feito minha primeira palestra como Embaixador do Projeto Fedora no Brasil. Sobre a palestra a respeito do GDB, também gostei do jeito que ela foi conduzida. Notei algumas falhas que precisam ser corrigidas, mas no geral a experiência foi muito boa.

Hoje, dia 23/10/2012, estarei na UNESP de Rio Claro para dar duas apresentações na Semana da Computação. A primeira palestra será sobre o Projeto Fedora. Vai ser a primeira vez que falarei sobre o projeto depois de ter me tornado Embaixador do Fedora no Brasil. Confesso que estou um pouco apreensivo, mas escolhi slides muito bons feitos pelo Paul W. Frields, ex-líder do Projeto e bastante competente em suas apresentações. Pretendo fazer um relato sobre a palestra na quarta-feira.

After a long time, here we are again :-). With this post I will start to talk about the integration between GDB and SystemTap. This is something that Tom Tromey and I did during the last year. The patch is being reviewed as I write this post, and I expect to see it checked-in in the next few days/weeks. But let’s get our hands dirty… SystemTap Userspace Probes You probably use (or have at least heard of) SystemTap, and maybe you think the tool is only useful for kernel inspections.

This post is actually a “reply” to Gary Benson’s Working on gdb post. I have been working with GDB for quite some time now, and even though the project officially uses CVS (yes, you read it correctly, it is CVS indeed!) as its version control system, fortunately we also have a git mirror. In the end, what happens is that almost every developer uses the git mirror and just goes to CVS to commit something.