First off, a debugger is a program that allows you to follow the execution of a program which you have written. gdb, the GNU debugger, is designed to help you debug programs compiled with GNU's compiler 'gcc'. gdb exists for almost all computer platforms supported by gcc. gdb allows you to step through your program (one line at a time), displaying the sourcecode line associated with the current command. It allows you to examine as well as alter the information stored in your various variables (allocated memory). By setting breakpoints at specific lines in your source-code you can quickly move ahead to particular places. For more thorough information on using gdb you can type help at the gdb command prompt; or you can check out the gdb man(ual) page.

Now, user-defined macros are very simple to create in gdb. Once you have started up gdb, you are given a command prompt where you can type help or any other command gdb understands. If you type help user-defined you will find the information on how to define your own macros. In succint fashion the way it works is like so:

1. type define followed by the name of the macro you would like to create. (and hit <RETURN>)
2. type whatever normal gdb commands you would like to perform simply by calling your macro. (hitting <RETURN> at the end of each command, just as you would if you were using the commands in gdb normally)
3. type end. (and hit <RETURN>)

Here is an example of the above instructions. Let us say we would like to have a quicker way to restart our program and clear all the displays we may have created over the course of debugging. Let us assume we never have more than 5 variables displayed.

Now, whenever we type restart at the gdb prompt, it undisplays the first 5 displays and runs the program again from the beginning.

But if you quit gdb (type quit) and then run it again (by typing gdb in your command shell) the user-defined restart command no longer exists:

so what we have to do is find a way to make sure our restart command will be there every time we run gdb. Luckily gdb allows us to specify a file on the command line that contains commands that are run right away as soon as gdb starts up. if you type and run gdb --help you will see one of the help lines shows us precisely where to tell gdb how to specify the file.

Now let us type our commands into the file ourmacros in our home directory. This is what the contents of ourmacros will look like:

We can now run gdb, passing it our file to have the restart macro ready for when we need it, so we don't have to type it in everytime we run gdb. We run gdb like so:

Sure enough, when we type restart it runs our home-made macro.

The problem now is, we don't want to have to type in --command=ourmacros every time we want to run gdb either. So there are two different solutions that I use:


The first is to create an alias.

This is a great solution for any global macros, in other words, macros that will apply to any program you decide to debug. Sometimes, though, you are working on a program for a long time time and you don't want to have to type in the same break points every time you start up gdb with a specific program. For this we have a slightly more complicated solution.

I decided to create a little directory under my home directory, and a little shell script that would handle such a problem. I created a subdirectory called .gdbmacros. ¹ In .gdbmacros I create a file with the same name as the program who's macros it will need to contain. For example, if I have a program named YServer, I would have a file in .gdbmacros called YServer. Now this is my little shell script, called ydb which does the rest of the work for me:

Now, when I want to debug YServer, I type ydb YServer and it opens gdb with all my macros specific to YServer all entered and ready to use.

While this entry does assume that the user is operating on some variant of UNIX operating system, almost all of the information holds true to whatever operating system you may happen to be using. The semantics for aliases or shell-scripting may be different, but you should be able to find some way to automate and hide your gdb macros with the help of the information presented here. Please feel free to make suggestions/corrections, or share your own experiences. I'm posting this information, because I had to figure it out on my own and it makes my life a lot easier. There may be better/simpler/more-elegant ways to do all of the above, but I have not encountered them yet.