Archive for the english Category

« Older Entries
Newer Entries »

GCC Summit 2008 – been there, got the t-shirt

Posted in english with tags , , , , , , , , , on Monday, July 14, 2008 by bauermann

I have finally found some time to write a bit about the GCC Developer’s Summit 2008, which happened one month ago in Ottawa, Canada (well, I didn’t really find time, since it’s past 1:30 AM now but still…).

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. :-)

2 Comments »

GCC Summit 2008

Posted in english with tags , , , , , , , , , on Monday, June 9, 2008 by bauermann

This year I will be attending the GCC Developers’ Summit again! I was there last year (sorry, trip report is only in Portuguese), had a great time and learned a great deal. This year it should be even more fun and interesting for me, since now I already know some people, have more GDB experience (one year and a half is not much, but still…) and am at least partially involved in a few current GDB developments (python scripting and reversible debugging).

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.

Leave A Comment »

some GDB and ltrace improvements

Posted in english with tags , , , , , , , , on Saturday, May 24, 2008 by bauermann

I thought I’d provide some updates on a few things my team has been doing on debugging tools.

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.

Leave A Comment »

Open Source Initiative logo

Posted in english with tags , , on Tuesday, May 13, 2008 by bauermann

Maybe I’m too slow, but just now I realised what the OSI logo probably means.

It may be viewed as a C with it’s open side turned not left, and not right, but down. So it’s not copyleft, but it’s not copyright either. It sits in the middle. It is a way of viewing OSI’s position between the Free Software Foundation (which uses copyleft, i.e., copyright “twisted” in order to free source code) and closed source software (which is protected by copyright laws).

It also looks like a keyhole. It’s not obvious to me how the keyhole concept should be applied here. Maybe it means open source protects user rights? Or protects something else? Or maybe open source is a way to peep into the secrets of software? :-)

Leave A Comment »

new sticker

Posted in english with tags , on Saturday, May 10, 2008 by bauermann

I need a sticker for my laptop. It should read:

free as in malloc.

Googling for the sentence reveals only two insipid results, so I don’t see much hope of getting it soon…

Leave A Comment »

vi, esc and tab

Posted in english with tags , , , on Thursday, May 8, 2008 by bauermann

I am, of course, a vi user (well, Vim actually).

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. :-)

2 Comments »

posting patches using Evolution

Posted in english with tags , , , , , , , on Saturday, May 3, 2008 by bauermann

Despite being a KDE person, I use Evolution as my mail client, including for reading mailing lists and posting patches. Up until now I’ve been doing the latter by attaching patches instead of including them in the message body, to avoid whitespace mangling and linewrap.

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!

3 Comments »

breaking code into reviewable patches

Posted in english with tags , , , , , , , , , , on Wednesday, April 30, 2008 by bauermann

As I mentioned before, I’ve been working on and off on adding Python scripting support to GDB, with Tom Tromey and Vladimir Prus. We did the work in a git repository, separate from the GDB main repo (which still uses CVS, by the way). Now came the time to get the work we did there, separate it in patches and post them for review on the gdb-patches mailing list.

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.

3 Comments »

new GDB release, and decimal floating point

Posted in english with tags , , , , , , , on Monday, March 31, 2008 by bauermann

GDB version 6.8 was released just a few days ago. I’m happy to have made my small contribution to it, mostly with development of decimal floating point debugging support. From the NEWS file:

“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.

Leave A Comment »

gdb’s backtrace command implemented in python

Posted in english with tags , , , , , , , on Monday, March 24, 2008 by bauermann

I’ve been working on Python bindings for exposing GDB’s frame_info, the internal structure it uses to keep track of the frame stack in the debuggee (or inferior, in GDB parlance). I got just enough working to be able to implement an equivalent of GDB’s backtrace command entirely in Python. The difference is that my version of the command prints older frames first and newer last, which feels more natural to me. :-)

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.

1 Comment »

« Older Entries
Newer Entries »