Relato das Apresentações na UNESP de Rio Claro/SP

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.

Apresentação “O Projeto Fedora”

Foi a primeira apresentação da noite, de acordo com a grade de programação. Começou meia hora atrasada, pois a organização pediu para esperarmos mais pessoas chegarem (estava chovendo bastante no momento, o que dificultou a locomoção).

Comecei a palestra falando um pouco sobre o Projeto Fedora. Acabei passando rapidamente pelas origens do projeto, uma falha que pretendo corrigir em próximas ocasiões. Dei muita ênfase na definição de comunidade e no que isso significa quando lidamos com software livre. Confesso que fiz algumas comparações com o Ubuntu, o que talvez não tenha sido uma boa idéia (de acordo com os guidelines do Projeto Fedora para Embaixadores). De qualquer modo, a mensagem foi passada e notei que algumas pessoas se interessaram em conhecer mais a respeito do projeto e da filosofia.

Pontos positivos: Creio ter conseguido informar as pessoas a respeito do projeto, com a ajuda dos ótimos slides do Paul W. Frields. É sempre gratificante dar palestras, mesmo que apenas uma ou duas pessoas no final acabem se interessando de verdade. Além disso, me senti bem por estar divulgando um projeto que respeita as liberdades dos usuários (ou pelo menos tenta fazer isso ao máximo), e que eu realmente uso e gosto.

Pontos a serem melhorados: Fazer uma palestra um pouco menos “pessoal”. É muito difícil conseguir isso, mas tenho a forte impressão de que minha orientação totalmente pró-software-livre acaba (às vezes) afastando algumas pessoas, que vêem no entusiasta por software livre uma pessoa “radical” e “xiita”. Preciso pensar um pouco a respeito do assunto…

A conclusão é que fiquei bastante satisfeito com o resultado da palestra. Percebi que, depois dela, algumas pessoas vieram comentar que estavam utilizando Fedora, ou que já andavam pensando em trocar de distribuição, que agora o Fedora era uma opção. O objetivo foi cumprido :-).

Apresentação “GDB Crash Course”

Creio que essa já é a quarta vez que apresento essa palestra, e a terceira vez junto com meu amigo Edjunior. Sempre que ela termina, fico(amos) com a impressão de que ainda não acertamos no ponto, e dessa vez não foi diferente.

A palestra começou em ponto, às 21h, e decidimos tentar uma abordagem um pouco diferente. A última vez que apresentamos a palestra foi no evento da Semana Integrada da PUC Campinas. Naquela ocasião, tínhamos optado por começar falando mais sobre os comandos do GDB, e depois mostrarmos como a coisa funciona, estilo hands-on. Dessa vez, resolvemos ir mostrando a prática junto com a teoria. Ficou melhor, e acho que a apresentação ficou mais fluida, mas ainda assim esbarramos no velho problema da interdependência dos comandos: quando íamos falar sobre breakpoints, precisávamos ter mostrado algum outro comando que só iria ser explicado mais à frente, que por sua vez iria precisar de outro comando, que iria precisar de breakpoints, etc. Enfim, no final acabamos sendo obrigados a pular alguns comandos, e a adiantar a explicação de outros, quebrando um pouco o fluxo dos slides.

Notei que algumas pessoas estavam bastante interessadas no GDB, talvez por já programarem há algum tempo. As outras, aparentemente, ainda não conseguiam ver muita utilidade para um depurador, mas mesmo assim tentavam aprender algo que talvez fosse lhes servir no futuro.

Já era de se esperar, mas mesmo assim não deixo de me surpreender quando vejo que uma palestra técnica consegue atrair muito mais atenção do que uma palestra “filosófica”, como foi a do Projeto Fedora. Talvez seja reflexo da sociedade em que vivemos, ou talvez seja apenas uma impressão errônea da minha parte.

A conclusão, finalmente, é que a palestra parece ter sido útil para algumas pessoas (mesmo que poucas), e isso nos dá ainda mais fôlego pra continuarmos tentando divulgar esse projeto pouco conhecido (mas muito útil) que é o GDB.

Agradecimentos

Não poderia deixar de agradecer primeiramente à organização da SECCOMP da UNESP de Rio Claro pelo ótimo evento. Fiquei surpreso com a infra-estrutura e, principalmente, com a receptividade das pessoas. Gostei muito do ambiente descontraído, e espero não ter decepcionado muita gente por lá com meus comentários informais e caipiras durante as palestras :-).

Também agradeço ao meu amigo Edjunior por ter me acompanhado até sua alma matter para me ajudar na realização da palestra sobre o GDB.

Até a próxima!


Apresentação na UNESP de Rio Claro/SP

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.

A segunda apresentação será sobre o GDB. Essa apresentação vai ser mais um crash course sobre como utilizar a ferramenta, e os slides estão disponíveis em https://github.com/sergiodj/gdb-unicamp2011.

Espero que ambas as palestras sejam bem recebidas pelo público! Volto depois pra contar como foi :-).

Abraços.


First Blog post, again...

Well, well. I really wasn’t entirely satisfied with Octopress, so I decided to change the blog engine yet another time!! Here it is, using blohg, a blog engine based on Mercurial (yeah, I know, nothing is perfect), and made by a Brazilian :-).

I intend to resume my activities in the blog pretty soon, especially because I have many things to share here. First of all, I will convert the old posts from Markup to rst.

Hope you like it!


GDB and SystemTap probes -- part 1

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. If that’s your case, I have a good news: you’re wrong! You can actually use SystemTap to inspect userspace applications too, by using what we call SDT probes, or Static Defined Tracing probes. This is a very cheap and easy way to include probes in your application, and you can even specify arguments to those probes.

In order to use the probes (see an example below), you must include the <sys/sdt.h> header file in your source code. If you are using Fedora systems, you can obtain this header file by installing the package systemtap-sdt-devel, version equal or greater than 1.4.

Here’s a simple example of an application with a one-argument probe:

#include <sys/sdt.h>

int
main (int argc, char *argv[])
{
  int a = 10;

  STAP_PROBE1 (test_program, my_probe, a);

  return 0;
}

As you can see, this is a very simple program with one probe, which contains one argument. You can now compile the program:

$ gcc test_program.c -o test_program

Now you must be thinking: “Wait, wait… Didn’t you just forget to link this program against some SystemTap-specific library or something?” And my answer is no. One of the spetacular things about this <sys/sdt.h> header is that it does not have any dependencies at all! As Tom said in his blog post, this is “a virtuoso display of ELF and GCC asm wizardy”.

If you want to make sure your probe was inserted in the binary, you can use readelf command:

$ readelf -x .note.stapsdt ./test_program

Hex dump of section '.note.stapsdt':
  0x00000000 08000000 3a000000 03000000 73746170 ....:.......stap
  0x00000010 73647400 86044000 00000000 88054000 sdt...@.......@.
  0x00000020 00000000 00000000 00000000 74657374 ............test
  0x00000030 5f70726f 6772616d 006d795f 70726f62 _program.my_prob
  0x00000040 65002d34 402d3428 25726270 29000000 e.-4@-4(%rbp)...

(I will think about writing an explanation on how the probes are laid out on the binary, but for now you just have to care if you actually see an output from this readelf command.)

You can also use SystemTap to perform this verification:

$ stap -L 'process("./test_program").mark("*")'
process("./test_program").mark("my_probe") $arg1:long

So far, so good. If you see an output like the one above, it means your probe is correctly inserted. You could obviously use SystemTap to inspect this probe, but I won’t do this right now because this is not the purpose of this post.

For now, we have learned how to:

  1. Include an SDT probe in our source code, and compile it;
  2. Verify if the probe was correctly inserted.

In the next post, I will talk about the GDB support that allows you to inspect, print arguments, and gather other information about SDT probes. I hope you like it!


My workflow with GDB and git -- part 1

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. But this is another discussion. Aside of this git mirror, we also have the Archer repository (which uses git by default).

My plan here is to show you how I do my daily work with GDB. The workflow is pretty simple, but maybe you will see something here that might help you.

Checking out the code

The first thing to do is to check out the code. I only have one GDB repository here, and I make branches out of it whenever I want to hack. So, to check out (or clone, in git’s parlance) the code, I do (or did):

With this, we have just cloned the GDB repository, and also added another remote (i.e., repository). This is useful because we might want to hack on a branch which is on Archer, but use GDB’s master branch as a base.

Create a new branch for your work

So, now it’s time to create a new branch for you. Here I use one of my little “tricks” (taught to me by my friend Dodji), which is the command git-new-workdir. This is a nice command because it creates a new working directory for your project!

Maybe you’re wondering why this is so cool. Well, if you ever worked with git, and more specifically, if you ever used more than one branch at a time, then maybe you will understand my excitement. In this scenario, having to constantly switch between the branches is not something rare. When you have uncommited work in your tree you can always use git stash, but that is not the ideal solution (for me). Sometimes I would forget what was on the stash, and later when I checked it, it was full of crap. Also, I like to have a separate directory for every project I am working on.

It is also important to mention that git-new-workdir is under the directory /usr/share/doc/git-VERSION/contrib/workdir/, so I created an alias that will automagically call the script for me:

So, after setting up the script, here is what I do:

Build GDB

In order to build the project, I create a build-64 directory inside my project directory (which, in the example above, is work/lazy-debuginfo-reading).

GDB fortunately supports VPATH building (i.e., build the project outside of the source tree). I strongly recommend you to use it.

As you may have noticed, I use -g3 (include debuginfo) and -O0 (do not optimize the code) in CFLAGS. Also, since some of the features I work on may affect code in other architectures, I use --enable-targets=all. It will tell configure to compile everything related to all architectures (not only x86_64, for example). At last, I specify a separate debug directory which GDB should use to search for debuginfo files.

Finalizing (for now)

After that, you will have a fresh GDB binary compiled in the build-64 directory. But that is not enough yet, since you will also want to test GDB and make sure you didn’t insert a bug while hacking on it. In my next post, I will explain what is my “testflow”. I hope it will be useful for someone :-).

Stay tuned!