[POST 0/4] catch syscall – Introduction

Hey.

I’ve been a little busy these days, specially because of GDB. I’m becoming more evolved with this project (since it’s also my job), and have already submitted my first patch (the link will open in a new window; it basically contains the “introduction” message for a series of 4 patches) to the developer’s mailing list. Well, and because of that, I decided that it would be good to “advocate” for the patch and for the feature it implements (and try to convince the developer’s that it’s worth accepting it!).

Basically, the patch implements a new feature which is called catch syscall. This is a long-waited feature in GDB, and there was even an attempt (made by Alan Curry in 2007). Now, this feature is pretty much ready to be included and I’m waiting for the reviews/comments this time (that’s the third try I do).

Probably, the explanation I’m gonna give here will be a series of 5 posts including this (just like I did with the patches), so that I’ll explain (in some detail, but probably not that much) how I did the things and why they are important for GDB in general. I also intend to make some comments about needed (at least IMO) modifications in the source-code. Hope that you like it.

So, as this is the first post AND the introduction of this new feature, I’ll begin explaining why would wee need such feature in the debugger. Basically, if you already know the strace utility, you probably already know why this is a cool thing to have :-). Otherwise, let me try to explain.

For most existing operating systems, the kernel exports an interface in order allow communication between it and userspace programs. This interface is popularly known as system calls, or just syscalls. As the name says, they are “special” functions that can be called from userspace. They are implemented directly in the kernel side, so userspace programs can request tasks to the kernel and it will perform them on behalf of those programs. If you ever programmed in your life, it’s almost certain that you used syscalls, even not knowing that you were doing it! (and specially because the first program you almost everyone writes is the “Hello World!”, which uses the write syscall). So, the importance is increasing to you, isn’t it? ;-)

The problem arises specially when you want to know what are the syscalls called by the program you’re debugging. As I said before, they are not always visible to the programmer. For example, the “Hello World” example that you may have written can be coded as:

printf (“Hello World!\n”);

And only after the compilation process (actually not exactly, but anyway) it becomes (along with a bunch of other function calls):

write (…, “Hello World!\n”, …);

So, as you can notice, we don’t always have this information explicitly marked in our programs. But wait, why would I want to do this? Simple: because you’re debugging something, and when you’re doing this it’s useful to have as much information as you can. Of course, this is a “general” explanation and there are better ones, but I won’t spend my time with it. If you can’t realize why this is good to have, just keep in mind that it is :-).

Ok, continuing with the explanation, how can we track this info and know what syscalls are being called? That’s where the catch syscall feature becomes visible :-). It basically takes care of this “dirty work” and can warn you if the program being debugged called (or returned from) a syscall. Oh, and it can also “filter” some syscall so that GDB will only stopped if that syscall is called/returned. There’s no practical limit for filtering the syscalls, so you can ask GDB to keep track of as much as you want (of course if you ask GDB to keep track of too many syscalls it’ll slow down a little).

It’s also worth mentioning that the patch is implemented (currently) only for PowerPC, PowerPC64 and x86 architecture. It shouldn’t take a long time for me to be able to send the patch for x86-64 too, and I think people will eventually want to extend this to other archs as well.

So, that’s it. In the next post, I’ll try to explain how I did the architecture-independent part of the patch. Let’s see if I my explanations are OK ;-).