Er, I actually do have one more thing to say about the subject: GDB had one project accepted in the Google Summer of Code 2009. Oguz Kayral is the student working on it, and I am his mentor. He will add support for subscribing to inferior events (e.g., signals, process and thread stops, thread creation) from Python. One use case for which this is useful was given by an IRC user at the #gdb channel:

<LimCore> how to run gdb from command line, so that it will run ./foo.bin with arguments: foo bar baz and it will run it instantly without waiting for ‘r’; And if program segfaults then it will do ‘bt’ without waiting for the command. (and if program terminates normally then it will also just quit)

LimCore will be able to write a simple and short Python script using the events API to solve his problem.

Now, moving on to other items: my team has been asked to improve GDB support for the hardware debug facilities in embedded PowerPC processors (for more info about these facilities, see Chapter 10 of Book III-E of the Power ISA v2.06). I announced this work to the GDB mailing list back in early March, and got useful insight from Joel Brobecker.

Today I posted an update on where we are with this work. We have the following ready for both native GDB and gdbserver on Linux:

• one additional hardware watchpoint (two in total),
• four hardware breakpoints,
• one ranged hardware watchpoint.

And we still have the following features ahead of us:

• support for the two DVC (Data Value Compare) registers, which enable hardware-accelerated conditions for hardware watchpoints,
• two ranged hardware breakpoints.

Last and least, I was thinking of posting monthly GDB updates on what happened in GDB in the previous month as I did back in February, but I got busy and didn’t get around to it. I still entertain the idea though, so if you think it’s worth it, I’d be glad to know.

The latest two patches committed upstream are for creating convenience functions in Python, and fo manipulating a program’s stack frames as Python objects. So, what can you do with those? I’ll borrow an example from Tom Tromey here: suppose you want to set a breakpoint which triggers only when the code is called by one specific function. You can create a convenience function like this:

import gdb
import re

class CallerIs (gdb.Function):
    """Return True if the calling function's name is equal to a string.
This function takes one or two arguments.
The first argument is the name of a function; if the calling function's
name is equal to this argument, this function returns True.
The optional second argument tells this function how many stack frames
to traverse to find the calling function.  The default is 1."""

    def __init__ (self):
        super (CallerIs, self).__init__ ("caller_is")

    def invoke (self, name, nframes = 1):
        frame = gdb.selected_frame ()
        while nframes > 0:
            frame = frame.older ()
            nframes = nframes - 1
        return frame.name () == name.string ()

CallerIs ()

And then create a conditional breakpoint using it, as in:

(gdb) break foo.c:42 if $caller_is ("some_function")

Or, to check the name of the grand-grand-caller of the code:

(gdb) break foo.c:42 if $caller_is ("some_function", 3)

Cool, huh? Now, why bother writing that big doc comment? GDB will use it as online help for the function you wrote:

(gdb) help function caller_is
Return True if the calling function's name is equal to a string.
This function takes one or two arguments.
The first argument is the name of a function; if the calling function's
name is equal to this argument, this function returns True.
The optional second argument tells this function how many stack frames
to traverse to find the calling function.  The default is 1.

One other patch which was merged in HEAD enables creating new GDB commands in Python, so you can write new commands to do some frame tricks too!

If you’d like to know more about the Python scripting work in GDB, I suggest you read the series of blog posts from Tom Tromey on this subject. It’ll give you a pretty good idea of what we have in the Python branch, and the direction we’re heading. Just keep in mind that some method names and syntax changed since he wrote that. Refer to the GDB manual in the Python branch (“make gdb.pdf” in gdb/doc/) or the example scripts (also in the Python branch, in gdb/python/lib/gdb/) for up-to-date details.

Qual não foi minha surpresa quando descobri que a solução pro meu problema não só já existe, como não exige configuração nenhuma e além disso já estava instalada e funcionando nos dois computadores! Chama-se Multicast DNS (mDNS), e faz parte de um conjunto de tecnologias de “zero configuration networking”, da qual o Apple Bonjour faz parte. No Linux, o serviço que implementa isso é o Avahi.

Para usá-lo no caso que eu tinha em mente (basicamente, ssh e scp) basta usar o hostname do computador a ser acessado e acrescentar a extensão .local. Exemplo:

hotblack% ssh hactar.local
hactar% ping hotblack.local
PING hotblack.local (192.168.1.2) 56(84) bytes of data.
64 bytes from hotblack.local (192.168.1.2): icmp_seq=1 ttl=64 time=0.328 ms

Ótimo!

Eu já tinha ouvido falar de Zeroconf e do Avahi, claro. Mas eu achava que era só para descoberta de serviços na rede (coisa que nunca precisei, pelo menos por enquanto (mas acho a idéia bem legal)), não sabia que integrava com DNS!

• publication of release schedule for GDB 7.0;
• merging of a handful of patches for Python scripting support (including ability to define new commands in python);
• new target supported (Ericsson’s DICOS on x86_64);
• revamp of thread support in Solaris;
• support hardware watchpoints in all i386 targets;
• ability to inspect extra signal information.

This is an incomplete list (doesn’t mention bugfixes, for instance) hacked up in the wee hours of the night, while waiting for sleep to come. If you are a GDB hacker who committed something interesting this month, I apologize in advance for not listing it here.

Anyway, this is the kind of thing we want to make easy to do in Python, so I decided to try to implement a solution using what we have in the Python branch. Tom Tromey already created the notion of convenience functions, which are functions that are implemented by GDB  that you can call in places where it accepts expressions, and he made it possible to implement such functions in Python. It follows that one can write a in_scope convenience function in Python which checks if a given variable name is valid in the current scope of the debugged program.

There were some missing pieces which I had to implement to get the in_scope function working (most notably, a method to get a string from a variable in the debugged program), and in the past few days I committed to the branch the patches which add those pieces. So now you can have the following script:

class InScope (gdb.Function):
    """Check if all the given variables or macros are in scope.
       Receives as argument a list of names separated by
       whitespace."""

    def __init__ (self):
        super (InScope, self).__init__ ("in_scope")

    def invoke (self, var):
        vars = set (var.string().split())
        found = set ()
        pc = gdb.get_selected_frame ().get_pc ()
        block = gdb.get_block_for_pc (pc)
        while block:
            for sym in block:
                if (sym.is_argument ()
                      or sym.is_constant ()
                      or sym.is_function ()
                      or sym.is_variable ()):
                    sym_name = sym.get_print_name ()
                    if sym_name in vars:
                        found.add (sym_name)
            block = block.get_superblock ()

        return vars == found

InScope ()

And use it like this:

Breakpoint 1, main (argc=1, argv=0x7fffffffe208) at /tmp/funcs.c:16
16        int i = 41;
(gdb) if $in_scope("i")
 >print "yay"
 >else
 >print "nay"
 >end
$1 = "yay"
(gdb)

If you save the script to ~/.gdb-in-scope.py, you can put the following in your ~/.gdbinit to load it automatically:

source ~/.gdb-in-scope.py

Now my goal is to cut out and submit upstream a set of patches to make the above work on regular GDB. The only problem is that I have the boring task of writing testcases and documentation for the code before I can submit it…

For now, If you want to use this script you can build a GDB from the branch, but be aware that the Python API as provided in the branch is subject to change.

First of all, I’d like to take the opportunity to encourage people interested in using this feature to experiment with what we have implemented so far. The reason is that if you still can’t do what you want with the current code in the Python branch, we’d love to hear what you miss and implement it. We are working on what is useful for ourselves, and trying to decide what other people would find useful. But it’s not possible to imagine everything that people want to use this for, or even most things. Please refer to this wiki page to learn what currently works, what we plan to implement, and how to grab the code from the Python branch.

Feel free to write to the GDB mailing list or show up in the #gdb IRC channel at Freenode to discuss this work and/or bring your use case to our attention, so that we can support it. I hope that with enough input from prospective users we can ship something that’s immediately useful for most people, and avoid having to jump through hoops later and have to shoehorn something that we forgot to cater for initially, risking breaking scripts out there or ending up with an inconsistent API.

Anyway, back to business: I have just committed the second patch in the Python series! It exports GDB’s value subsystem to Python scripts. Basically, GDB values are objects which represent data in the inferior (GDB jargon for the program being debugged), holding its address in the inferior’s addressspace, its type and so on. See the “Python API” section in the GDB manual if you want to learn more about it (yes, we are even writing documentation for the feature!).

I committed the first patch back in August, but I didn’t mention it here because it didn’t do anything the user would find useful, really. It was just groundwork for the rest (autoconf and Makefile.in changes, a ‘python’ command in GDB which basically does nothing useful, initial documentation…). Still, it was about 1500 lines long (not counting the patch’s context)! This shows how much work it is to integrate Python support in GDB. I almost regret having joined this effort.

The second patch also doesn’t allow the user to do anything useful yet, unfortunately. But it is noteworthy because it is a base upon which a lot of other Python support code depend upon. Also, it’s the first committed patch which actually exposes something from GDB to Python. It took a while to get this code ready for two reasons: one was that there was a long discussion regarding how the syntax of acessing struct/union/class elements. The other was that implementing the Value class involved playing with little-documented aspects of Python’s C interface, and it took me time to discover how to do what I needed.

Now my next step is to choose the next patch from the Python series to submit upstream, and get it ready for posting (i.e., fix FIXMEs, add testcases and documentation). This brings me to another thing I’d like to mention. Back in April when I first prepared the Python patch series, I naively thought that after cutting them out, it was just a matter of posting them, iterate through a few review/rework steps and they’d be committed. Simple enough. But here we are in mid-October and just two from nine patches went in (now it’s more like 15 patches in total)! What happened?

The problem is that we’ve been working in the branch in an experimental and exploratory way, just hacking together enough to get something useful done. This was necessary because we didn’t know exactly what we would want to expose from GDB to Python, and how we wanted to do that. As we progressed and discussed the results, things started to become clear. The problem is that now we have a lot to clean up, voids to fill, and above all documentation and testcases to write. This takes time.

At least, that was the problem with the first two patches. I noticed Tom Tromey started to write more documentation and tie more loose ends than in the beginning (me? I’ve just been working on the first two patches until they were ready. Didn’t write sexy new stuff since then…), so there’s hope that the next patches will be easier to work with. We still lack a lot of tests for the testsuite, though…

Pra que me prender a um celular/PDA no qual eu não posso instalar os programas que eu quiser, e que eu não posso fuçar pra tentar fazer funcionar do jeito que é mais útil pra mim (olá, supporte a ogg )?

O N810 também é uma boa opção (eu tentei comprar um já, mas não achei pra vender na época), se você ignorar o fato de que ele não é um telefone. Pra mim não é uma limitação séria, já tenho um de 200 reaus (isso na época, hoje não vale nem dez…) que faz e recebe chamadas.

In summary, I had a blast there! I was in last year’s summit and enjoyed it and learned a lot from it. But this time I already knew GDB people and they knew me, and I am involved in a couple of current developments and have more experience with the project, all of which made some difference. And everybody there is very friendly, of course, even if they never heard of you before. In fact, Ian Taylor in his welcome presentation urged people to be friendly to newcomers since GCC and the GNU toolchain need new blood.

There was a good number of GDB-related events: a GDB talk and two debugging information talks, a debug information BoF, an informal GDB get-together and a GDB BoF. Unfortunately I know squat about GCC internals (I intend to learn more about it, but didn’t have a chance yet) so the two debugging information were above my head, and I absorbed little. The GDB talk was interesting but since I follow the GDB mailing lists I already knew most of what was presented.

The debug information BoF was interesting, especially since the discussion didn’t focus so much on the two competing approaches to improve debug information (which was the original point of the BoF), but mostly on what should be expected from debug information generated by GCC (i.e., what a debugger should be able to do with it, especially at higher optimization levels), and how its quality can be tested in the GCC testsuite.

The most interesting events for me were of course the GDB get-together and the GDB BoF. The former was a table reserved for us at lunch one day (thanks for organizing this, Joel Brobecker!) where folks interested in GDB would get to see each other faces and talk about random stuff (GDB-related or not). It was fun, and we were able to throw some ideas around about things such as conversion of the GDB repository from CVS to Subversion, the patch review process, and even about rewriting GDB in C++ (which is a hot thread in the GDB mailing list today!). I have a picture of the event:

If you follow the link you can see the notes with the name of each person in the photo above.

The GDB BoF was very interesting, and it felt weird to be at the front (thanks for inviting me Daniel!) discussing current GDB issues with Daniel Jacobowitz, Tom Tromey, Pedro Alves (the other people at the front) and the other GDB maintainers and developers in the room.

We nailed down some pending issues that were being discussed in the mailing list at the time regarding Python scripting support (man, it’s so much easier to decide things face to face rather than by e-mail!), and also discussed a bit of reversible debugging, multithreading GDB itself, GDB scalability, what to do regarding the next release (in a nutshell: wait about a year from the last release so that all the cool stuff which is being worked on right now gets in and settle down), moving the bugs database from GNATS to bugzilla (thanks for doing this Tromey!) etc.

Also after the BoF Pedro Alves gave a very good improvised tutorial on the GDB event loop which he has been studying for the past few months. It felt like cheating, to get all that knowledge in what, half an hour? Thanks so much Pedro, it was awesome.

And of course all the interaction with the people who were there, like Joel Brobecker (playing tennis is more serious than I thought!), Gaius Mulley (Pink Floyd!), Anmol Paralkar, Ramana Radhakrishnan and many others (I don’t even try to enumerate, just a random sample).

I shared a suite in Ottawa with David Edelsohn and Kenneth Zadeck, which was an interesting thing in itself. Heading back to the hotel felt like going to an extended GCC summit. I almost learned something about GCC internals (SSA, LTO, register allocation) and also had very interesting conversations in general.

And of course my one week of backpacking in Canada after the summit, which was another blast.

Also, there will be a fair number of GDB-related events this time, and I look forward to all of those: a GDB talk and two debugging information talks, a debug information BoF and an informal GDB get-together. I look forward to the GDB-related conversations we’ll have in the last one. Even more so if we do the get-together in a bar, around some beer.

I also look forward to the closing party at Vineyards, of course. I will finally eat again that bumbleberry pie…

Update (2008/07/15): I just wrote the trip report.

Just today Carlos Seo committed a patch to GDB adding support for writing AltiVec (PowerPC’s SIMD instructions) registers to corefiles when using the gcore (or generate-core-file) command. This support will show up, then, in the next GDB release. He also had a patch committed last year, in time for GDB 6.8 release, adding support for reading AltiVec registers from core files generated by the Linux kernel, starting from version 2.6.24 (kernel patch provided by Mark Nelson).

Luis Machado posted in February a patch for ltrace which fixed a number of ABI-related bugs for PowerPC 32-bits and 64-bits. The patch was committed in March. The ltrace maintainer has been out for quite a while now, so I don’t think this will appear in an official release any time soon, but it will surely be picked up by the distros.

Going back to GDB, Luis implemented displaced instruction stepping for PowerPC, helping a bit with the non-stop multithread debugging effort carried out by CodeSourcery. The patch didn’t go in yet, it’s awaiting review. He’s also been monitoring the non-stop patches and testing them on PowerPC, having already provided some feedback and pointed out a few regressions.

A long time ago I had a nice idea, which unfortunately wasn’t very practical so I didn’t use it for long: I remaped my Tab key to work as Esc, so I could more easily switch modes. I say it wasn’t very practical because getting used to it meant that I would have the wrong muscle memory whenever I was in front of another computer (this was also the reason why I used the Dvorak layout for only a few months).

I couldn’t help but smile today when I found out that the computer terminal where Bill Joy developed the original vi had the Esc key where the Tab key is nowadays.

But this method is inconvenient sometimes: when you want to comment on a patch posted on the list, portions of that patch (which may include long lines that shouldn’t wrap) will show up in the message body and you can have trouble. This is a problem especially when the poster also sent their patch as attachment, because you will most likely need to copy & paste the patch into your reply window and things will get mangled right there.

Turns out that there is a way to include a patch in the message body in Evolution’s compose window and it will get through unmaimed: select the Preformat option in the paragraph style dropdown, and then paste in your patch or use the Insert -> Text File… option.

Caveat: Older versions of Evolution converted tabs to spaces when pasting text, so you had to insert it from a text file to preserve whitespace. I just tested with version 2.12.3 from Debian (package version 2.12.3-1), and pasting a patch containing tabs worked fine so the bug has been fixed.

Thanks Klaus Kiwi for the tip!

This is the tale of my patch-producing efforts. I’m sorry, it is most likely boring for everyone but me. Still, I wanted to write it down so you are free to stop reading the post here.

Anyway, back to where I was: I (foolishly, perhaps?) volunteered to create the patches. One reason for me to do that is that I actually enjoy working with and learning about source code management and related issues, and this was a good opportunity for me to improve my git-fu (since I thought git could help me do the job in a sane way, which fortunately proved to be the case).

I say foolishly because I thought it wouldn’t take too much time to cut out the patches, since I knew what I would have to do… The task of course took longer than I expected, in part because of unforeseen autotools woes, but of course also because I underestimated the effort (I am an optimist).

Here is the method I used:

First of all, I wanted to update the code to the latest CVS version of GDB, because the work in the git repo was done based on a CVS version from February… Nothing to see here, actually. I just created a new branch with the latest CVS update, and rebased the commits on top of that. In hindsight, I should have merged the new CVS update into the python branch, which would have made me deal with less conflicts. I used rebase because I thought I would cherry pick the commits later, so I wanted each of them refreshed.

Then the real fun began. I started using interactive mode of git rebase to squash related commits together (to form the patches), and reorder them. I quickly realised that with this approach I would have a bit of difficulty with commits which touched different areas of the code and crossed the borders I had in my mind for the patches I wanted to generate. I would have to first split those into smaller, more behaving commits and only then squash them with other similar changes. That seemed to be more work than really necessary.

Also, the older commits did things in ways and places which were later changed, and it looked like I would have some trouble reconciling older and newer code to fit in one patch (maybe not though, maybe that would be taken care of more or less naturally). Also, I would need to take some time to familiarise myself with the commits in the branch, because I only authored some of them. The “shuffle commits around” approach wasn’t looking very promising.

I then turned to a different strategy: I generated a big patch containing all of the code in the branch, and applied it (using the plain old patch command) on top of a clean branch which contained only the CVS HEAD version I was using as a base. All I needed to do now was to selectively add to the index the changes that I wanted to include in a patch and then commit those changes together. And repeat the process for the next patch and so on.

It proved to be a good approach, especially because of the interactive mode of git-add. This mode asks you about each change inside a modified file, letting you add that change to the index or skip it, leaving it in the working directory for a future commit. git add -i streamlined the “change picking” process quite a lot, and made the patch-cutting almost mechanical. (By the way, this feature is also available in Mercurial, with the Record extension. I even believe (not sure though) that the Mercurial extension predates git add -i) (I don’t know if Bazaar has it, would be nice to know).

In this phase of the process, git rebase -i was useful. Sometimes I came accross a change in the working directory which would fit better in a patch which I had already committed. It was simply a matter of committing that change and then shuflling it back and squashing with the proper patch.

At each commit I pushed the changes to a pristine repo which I used to build GDB and guarantee that each patch included all the changes it needed.

Voilà, at the end of the process I had a git branch where each commit corresponded to one patch which I wanted to send to the mailing list.

“GDB now supports debugging C and C++ programs which use the Decimal Floating Point extension. In addition, the PowerPC target now has a set of pseudo-registers to inspect decimal float values stored in two consecutive float registers.”

The feature was actually developed by several folks. Ben Elliston started working on the feature, and then passed it on to Wu Zhou. I took up where Wu Zhou left and implemented more complete support for decimal float types. Luis Machado also helped me and posted some patches of his own. The work amounted to a total of about 12 patches.

It means that you can now use GDB (version 6.8 or later) to debug programs which make use of the proposed C extension for decimal floating-point arithmetic (i.e., the _Decimal32, _Decimal64 and _Decimal128 types). The first GCC release with support for this extension was GCC 4.2.

Why is decimal floating point useful? It avoids the unexpected surprises and rounding errors which inevitably come with binary floating point. It’s not that decimal float is more exact or precise, it’s just that it behaves just like we are used to and were thought in school in terms of representation and rounding.

GDB itself can provide an example:

(gdb) p 1.2l
$1 = 1.2000000000000000000433680868994202
(gdb) ptype 1.2l
type = long double
(gdb) p 1.2dl
$2 = 1.2
(gdb) ptype 1.2dl
type = _Decimal128

You can see that the actual value used to represent 1.2 in binary floating point is slightly larger than 1.2. Why is that? It’s because to express 0.2 in binary float you need an infinite number of digits, so what ends up being stored is the closest number possible to represent in binary. The difference is almost nothing, but this error will propagate in computations and eventually be big enough to be noticed. That’s why in some application domains (e.g., finance and civil construction), you are actually required by law to use decimal floating point to perform calculations.

More information about decimal float can be found in Mike Cowlishaw’s page.

Here’s the output I get:

(gdb) rbt
#2 0x080483bb in main at ../../src/examples/funcs.c:15
#1 0x08048391 in f1 at ../../src/examples/funcs.c:10
#0 f2 at ../../src/examples/funcs.c:5
(gdb)

A little bit more information, and the definition of the Python command which does the above can be found in my post to the mailing list. The code is on the git repo for the Python work.

I find it interesting that he chose to implement it in C++. I’m glad that the “let’s do it in C because everybody knows it” mantra that so frequently determines the programming language of open source projects doesn’t always prevail. Perhaps this will help weaken the argument?

And yes, I know about KDE. It’s the exception that proves the rule.
Besides, don’t forget that GNOME, the project created to react to it is in C, using the horrible GObject monstrosity.

The work is being done in a git repo hosted by gitorious. More details here.

This looks very promising.

Update – 2008/03/15: Sorry, I was a bit cryptic in this post. It’s not really about enabling debug of Python programs using GDB (which is a neat idea, and I hope to play with it sometime). It’s about integrating a Python interpreter into GDB and exposing its internals as an API to be used by Python scripts. This will enable people to automate and extend GDB functionality using Python. This feature has been asked many times before, and finally is being addressed. Should open many possibilities.

In addition, you need pay attention to the import wizard’s window to see if all images were downloaded correctly. If an error occurs, the only indication is a small red cross on the image itself. There’s no warning dialog or status message telling you that something went wrong. You have to check each image. I opened a bug report about this too.

This is actually the first problem I had with digikam, and have always had a great experience with it. I really recommend the application to organize your photos (well, just avoid version 0.9.3 ). Along with amarok, I think it’s one of KDE’s killer apps.

Anyway, I started this post to suggest a game which I recently started playing and found very interesting and fun. I know, after  mentioning that two of my favorite games were NetHack and Koules I don’t deserve much credit, but still…

’tis called Neverball,  and is one of those simple, but yet effective games. There’s a ball and you have to make it through the game level while collecting the coins. The thing is, you don’t control the ball. What you actually control is the level floor beneath it. So what you do is tilt the floor to make the ball roll in the direction you want, at the speed you want (well, if you are a good player!).

By the way, since I’m talking about games: there’s one other I find very good. Since I won’t write a full post about it, I might as well mention it here: it’s Pingus, a free Lemmings clone. It’s very well done with good graphics and sound.

First of all, I’m not trying to do rigorous analysis here but just do some estimates to make a decision for personal use. Still, if you find something in my method which invalidates the results I obtained, I’d be glad to know about it.

To know the memory consumption of each desktop system, I simply started a fresh session in that desktop, opened a terminal and obtained a process listing with ps -e. No other program was opened at the time. Because I did this using a new user account, the test was made with the default configuration and default loaded programs of each desktop system.

Since the important figure in the ps output is the RSS (resident set size) column, I also turned off the swap partition in my computer. The ps manpage says that the RSS field doesn’t count swapped memory from the process. Good thing I noticed this before it was too late!

Here is the result for KDE:

And here is the result for XFCE:

So, XFCE uses 152MB of RAM, versus the 191MB KDE uses. Not bad, almost 40MB (20%) less!

That’s not the whole story, though. I also wrote down the output of the free command as a sanity check.

Using KDE:

Using XFCE:

Look at the “used” column, in the “-/+ buffers/cache” line. That is the actual memory amount being used by the running programs in the computer.

This is a very interesting and surprising result: at the end of the day, XFCE actually uses more memory than KDE! Why, if adding up the resident sizes of the processes from each desktop system you get a different conclusion?

One explanation would be that KDE actually shares more memory between processes than XFCE. Its programs most probably have a greater number of shared libraries in common, which enables the kernel to use the same memory pages for the text section of those libraries accross process images. Unfortunately I didn’t collect data to test that possibility, and it’s late at night now. But it makes sense.

The bottom line, surprisingly enough, is that you should stick with KDE to preserve memory. Or switch to a bare-bones window manager instead of a complete desktop system, like IceWM, Window Maker, Blackbox or something else. But I’m too spoiled by the amenities of a good desktop to do that.

By the way, the tests were made with KDE 3.5.8 and XFCE 4.4.2 under Debian GNU/Linux unstable (updated on 2008/01/06) on a 32-bit x86 machine.

http://sourceware.org/ml/frysk/2008-q1/msg00004.html

You have to do a commit just with the rename operation (identical file contents), and then modify it. Sheesh, good to know about that!

I recall I had a similar problem with Subversion once… I think it was refusing my commit or something. I had to go back and do just the rename, commit and then modify the file.

Bom, ir para lá foi uma oportunidade que surgiu do nada, eu nem imaginava que poderia acontecer. Uma colega minha dos Estados Unidos comentou no canal de IRC do nosso departamento (sim, no Linux Technology Center a gente usa IRC pra coordenar times e projetos!) que poderia ser útil eu ir lá conhecer membros da comunidade do GDB, para facilitar a discussão de algumas coisas que na época queríamos propor para a comunidade. Eu aproveitei a bola quicando na área e falei pro gerente (que também estava no canal): “é uma idéia legal, o que você acha?”. Quando eu falei isso tinha quase certeza de ouvir um “não vai dar” como resposta, mas qual não foi minha surpresa quando ele disse “mmm… ok.”!

Um mês depois lá estava eu desembarcando em Ottawa, sem saber o que esperar de um evento como esse. Eu estava nervoso, pois tinha certeza que todo mundo lá manjava muito mais que eu. Afinal, eu estava trabalhando com GDB e envolvido com questões de baixo nível (Linux ABI, arquitetura Power, dynamic linking, etc.) fazia apenas uns 6 meses. Tinha gente lá trabalhando com isso faz 10 anos ou até mais. Mas o pessoal é muito bacana e me deixou bastante à vontade. É uma comunidade bastante amigável, isso posso dizer.

Não tinha tanta gente do GDB por lá. Houve um mini-BoF em um café da manhã, e tinha umas 5 pessoas na mesa. Mas foi muito útil conhecer pessoas com quem interajo nas listas de discussão, e deu para esclarecer algumas dúvidas com relação ao código e outros assuntos sobre os quais eu queria conversar. Além disso, o pessoal gostou de saber que temos um time trabalhando forte com GDB aqui.

Uma coisa que me surpreendeu foi ver que muito pouca gente trabalha no GDB como foco principal. A maioria dos contribuidores trabalha em outras coisas (toolchain, GCC, algum processador, sei lá) e mexe no GDB para adaptá-lo a esse outro objetivo. Isso me ajudou a entender e contextualizar melhor o que vejo nas listas, e trabalhar melhor com ela.

Tudo isso facilitou a minha interação com a comunidade. Agora entendo um pouco melhor sua dinâmica, e conhecer a pessoa por trás de um endereço de e-mail ajuda nas discussões e patches (digo isso tanto no lado de eu conhecer a comunidade, quanto de eles me conhecerem). O fator humano sempre tem um certo peso.

Bom, obviamente não posso deixar de falar do evento que teve no final: o pessoal fechou um bar (Vineyards), e a gente passou a noite lá, com direito a open bar e boca livre! A variedade de cervejas que tinha lá era impressionante, e eu provei um dos melhores doces que já comi até hoje: a Bumbleberry pie!

Coloquei as fotos da viagem no flickr. A maioria são de meus passeios pela cidade, tirei muito poucas do summit em si. Estas são as principais:

• IBMistas presentes,
• meu crachá,
• pessoal no bar,
• menu do bar: capa, índice, conteúdo,
• bumbleberry pie.

http://sourceware.org/ml/gdb-patches/2007-02/msg00000.html

Ele conserta o comando “disassemble” para q ele leia corretamente instruções dos processadores Power4, Power5 e Power6 (q ainda não foi lançado). É um patch pequeno, mas a dificuldade não foi escrever aquelas duas linhas, e sim saber o q estava acontecendo.

Aqui está o e-mail de confirmação do commit:

http://sourceware.org/ml/gdb-patches/2007-02/msg00091.html

Pois bem, aqui está a nova versão do script. Como ele já está fazendo tudo o q eu queria, talvez esta seja a versão final.

Dependendo do argumento passado, o script faz um backup completo, um backup incremental contendo as diferenças desde o último backup ou um backup diferencial, q é o nome q eu dei para um backup contendo as diferenças desde o último backup completo (ou seja, ignorando os incrementais). Este último modo serve para consolidar todos os backups incrementais em um só, evitando q seja necessário restaurar trocentos backups incrementais…

Minha idéia inicial era fazer o backup incremental a cada dois ou três dias, mas obviamente não fiz isso. Hoje fiz meu 1º backup incremental, e ele ficou bem maior do q eu esperava: 60 MB. Isso pra uma semana de dados!

O principal culpado é o diretório ~/Mail, q contém umas pastas de e-mail local em formato mbox (ou seja, todos os e-mails da pasta em um único arquivo). Isso significa q qdo chega uma nova mensagem, a pasta toda vai pro backup. Pra uma pasta de 50MB, isso não é muito bom… A solução é simples: converter pro formato maildir, q guarda cada mensagem em um arquivo separado. Assim, só as mensagens novas vão para o backup.

Se alguém se interessar, aqui está o script que eu fiz: backup-home.sh

I just found out about this feature in KDE which I suspect will become very handy for me from now on: have the taskbar’s clock show the time in different timezones:

To enable it, just right-click on the clock, select “Configure Clock…” and then the “Timezones” tab.

GNOME, of course, has the same feature. That’s how I had the idea to search for this in the first place…

Acabo de descobrir uma funcionalidade do KDE q vai se tornar muito útil daqui pra frente: o relógio da barra de tarefas consegue mostrar as horas em diversos fusos horários:

Para configurar isso, basta clicar com o botão direito no relógio, clicar em “Configure Clock…” e selecionar a aba “Timezones”.

O GNOME, claro, tem a mesma coisa. Aliás, foi assim q tive a idéia de procurar isso no KDE.

http://marc.theaimsgroup.com/?l=selinux&m=116326731410199&w=2

And here’s a practical example on how to present your arguments on a mailing list discussion:

http://marc.theaimsgroup.com/?l=selinux&m=116076869107136&w=2

</tongue-in-cheek>

Hoje fui mexer no notebook e ele começou a fazer uns “cleks” estranhos, mais ou menos periodicamente durante algumas horas. Vixe, taí uma boa hora pra começar a tomar uma atitude com relação a backup!

Não que necessariamente tenha algo errado com o HD… eu li em algum lugar (não lembro onde, mas lembro q a fonte era confiável) q alguns modelos de HD fazem esse tipo de barulho de vez em quando como parte do funcionamento normal deles. Então não é nada de mais. Mas sei lá, vai que é algum problema…

Já que eu ia fazer outro backup, resolvi pesquisar melhor e encontrar algum método mais prático do q o backup tosco q eu fiz das 2 últimas vezes (sair catando arquivos e diretórios importantes, jogar num lugar só, gerar um iso e queimar). Com isso eu espero diminuir o meu tempo médio entre backups, q hj é de 6 meses. (sim, antes de maio meu backup anterior havia sido em novembro do ano passado).

No fim das contas, depois de ler muitos artigos e percorrer diversos resultados de busca do Google, resolvi ficar com um comando chamado dar (eu sei, eu também pensei nessa piada), que significa Disk ARchiver. Pelo que pude ver é um utilitário bem maduro, usado por diversas pessoas inclusive profissionalmente. Algumas vantagens que me chamaram a atenção:

• O que eu mais gostei nele é que você consegue extrair do backup um arquivo que ele chama de catálogo: é uma lista de todos os arquivos do backup, com as datas de modificações. Assim é possível usar esse catálogo pra fazer um backup incremental da próxima vez.
• Outra coisa muito interessante é que ele consegue dividir o backup em diversos arquivos (você especifica o tamanho que quer na linha de comando) pra poder gravar em mais de um CD, por exemplo (eu estava precisando disso!).
• o dar compacta os arquivos antes de fazer o backup. Ele compacta cada arquivo individualmente. Não é tão eficiente, mas vc garante q mesmo q a mídia corrompa, vc só perde os arquivos realmente afetados pelo defeito.

A parte complicada é gerar uma linha de comando que faça o backup q vc quer. As opções do comando são tão diversas e numerosas quanto as do tar. Eu usei esta página como base, e também o tutorial oficial do dar. Estou anexando a esta entrada o script que criei para gerar meu backup. Ainda quero melhorá-lo para que ele também faça backups incrementais, mas isso fica pra outro dia.

Uma parte tediosa foi gerar a lista de diretórios que não entram no backup. Isso é importante pra mim pois como não tenho gravador de DVD, preciso minimizar o número de CDs gravados, e meu $HOME está com uns 25 gigas… Nessa tarefa, o kdirstat foi extremamente útil. Ele consegue rapidamente gerar um relatório dos maiores arquivos e diretórios, e tem um modo de visualização gráfico que permite encontrar facilmente os maiores culpados pelo consumo do disco.

O resultado disso é que no fim das contas só precisei fazer backup de 2.4G, e isso coube em 3 CDs (ocupando 1.8G no total. Nada mal, a compactação economizou um CD).

No fim das contas, minha idéia para o procedimento de backup é a seguinte:

1. a cada dois ou três dias, fazer o backup incremental e copiar pro pen drive
2. a cada duas ou três semanas fazer um backup diferencial desde o último backup full pra não precisar ficar acumulando infinitos backups incrementais e quem sabe economizar espaço no pen drive
3. a cada dois ou três meses fazer um backup full

É isso. Espero que tenha sido útil. No mínimo pra fazer cair a ficha em mais gente e fazê-las correr atrás de um esquema de backup.

Se alguém se interessar, aqui está o script que eu fiz: backup-home.sh

Eu já ia meter o dedão no power, lamentando o fsck no dia seguinte e a possibilidade de inconsistência no sistema de arquivos (será q eu ia perder alguma coisa?) quando lembrei da famosa Magic SysRq.

O problema é que eu nunca tive saco pra decorar aquelas benditas combinações de teclas…

Tentando combinações aleatoriamente, descobri q Alt+SysRq+x ou Alt+SysRq+z mostra uma ajuda online, com algumas das combinações possíveis! A partir daí, consegui sincronizar os buffers de disco, remontar o HD como somente-leitura e rebootar a máquina com segurança. Ganhei o dia.

Taí uma dica que vale a pena lembrar: nos momentos de desespero, Alt+SysRq+x. Ao invés de umas 3 ou 4 seqüências aleatórias, vc só precisa decorar uma…

Não que tenha sido perfeito: Eu deveria ter colocado algumas piadas e tentado envolver o pessoal. Havia muito conteúdo pra passar em pouco tempo, e acabou ficando meio pesado nesse sentido. Mas também não dá pra querer acertar tudo logo de cara, então pra mim foi ótimo.

O mais legal é que o pessoal prestou atenção! Eu vi pessoas fazendo anotações, e inclusive uma menina filmando! Deu pra perceber isso na hora das perguntas também, pois foram todas bem dentro do assunto, e uma menina inclusive achou uma contradição no que eu falei (realmente, eu havia me expressado mal).

O Leonardo Garcia, outro membro do LTC Brasil, apresentou uma palestra sobre o processador Cell da IBM, Sony e Toshiba. Foi muito bem apresentada, falando desde o papel do processador na evolução dos videogames de nova geração até arquitetura interna, modelos de programação e outras aplicações.

As nossas palestras fizeram parte da 1ª Semana de Telemática do CEFET-SP. Foi muito legal poder contribuir com o evento.