GDB for Beginners

Author

Roman Kargin
Copyright (c) 2012 Roman Kargin
Used by permission.

Introduction

On the Internet you can find a lot of GDB tutorials; ranging from the simple ones, which give you a basic reference for GDB, up to the big tutorials and documentation (including the official ones). Of course, none of these are written in the context of Amiga OS4, because for the rest of word AmigaOS is very obscure, and as result all those GDB tutorials are oriented towards x86/UNIX, or occasionally PPC/Sparc/Alpha based Unixes (although those still look pretty much the same, as it is still UNIX). In the case of Amiga OS4, the SDK documentation just includes the official GDB docs, which cover just the GDB itself without taking Amiga OS4 into account.

Some of you may remember that GDB on Amiga OS4 worked reasonably well on the early versions of the OS, prior to the first releases of OS4.1, which brought a lot of changes, some of which caused GDB to stop working properly. But with the release of Amiga OS4.1 update 3, GDB once again started to work more-or-less as expected, and lately (with release of Update 4) it is usable again. As result, all of the information in this article are based on the GDB from latest SDK 53.20 (GDB version 6.3, 2005.07.19 build) and Amiga OS4.1 update4.

7/0.RAM Disk:> gdb -v
GNU gdb 6.3 (AmigaOS build 20050719)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "ppc-amigaos".
 
7/0.RAM Disk:> 

What is GDB?

GDB is not just a simple debugger or disassembler, but a full debug environment that gives you the ability to debug your program in real time, disassemble your code, dump or disassemble memory areas, attach to running processes (e.g. a commodity that is already running), step through source code or assembler instructions, set breakpoints on labels or addresses, display variable values, and just about anything else a serious programmer may need.

So of what use is GDB to a beginner programmer? Why have GDB on Amiga OS at all? Put simply, GDB enables you to determine exactly what is happening inside your program, and help you figure out why it runs into trouble. For example, if you wrote a program, but it doesn't work how you expected it to, and/or it crashes. You can use GDB to set a breakpoint somewhere before the problem, and launch the program. The program will run until it reaches the breakpoint, and then you can check the state of the program, its variables, dump memory buffers, inspect the stack and see exactly what is going on. Then, after you have investigated everything you need to look at, you can continue execution of the program, or step over the code (either at source code or machine code level), to see what is happening.

GDB on Amiga OS4 is also good for any research of work, for example you can find out at which address OS4 loads a relocated ELF, which addresses it uses for kernel areas, what happens when programs calls the system parts of OS and so on. Of course, it is entirely possible to do some non-interactive debugging without GDB, like plain disassembly (with "objdump" for example), but static disassembly is not real time debugging, so you can't check what happens exactly at a given moment of a program's execution.

Sometimes it is useful to be able to use a debugger when you have no documentation to hand, and don't know how some functions behave, or what they return and where. Also, it can sometimes be the case that even the documentation is wrong and the debugger can help you confirm exactly what is wrong to fill out a proper bug-report or for creating a patch/fix.

When using GDB, it is necessary to include debugging information in the binary. This information will you to reference functions and variables by their names, and set breakpoints at named functions, like at "main()" to debug from the start of your program, or function "foo()". It is possible to debug binaries which have no debugging information at all, but then you will not be able to follow the high-level source code (usually C/C++), and will only be able to examine the assembly code. Without debug information you are usually forced to start at the "_start" label, which is where the all real code start (which is in the C/C++ library startup code for C/C++ programs).

GCC has many flags to specify the kind of debugging information to be included in the binary, including -g, -ggdb, -gstabs and -gstabs+. The only flag which is recommended for use on Amiga OS4 is -gstabs. So, whenever you wish to create a binary with debugging information, you should add "-gstabs". Other ones may or may not work, but to avoid any issues just use "-gstabs". The same is true if you want to just use "addr2line" to find the address of a crash from a stack trace.

First Steps

Lets start with the simple Hello World example:

7/0.RAM Disk:> type hello.c

1. include <stdio.h>

main() {

   printf("just hello");

   return 0;

}

7/0.RAM Disk:> gcc -gstabs hello.c -o hello
 
7/0.RAM Disk:> gdb -q hello

(gdb) run
Starting program: /RAM Disk/hello 
just hello
Program terminated with signal SIGQUIT, Quit.
The program no longer exists.
(gdb) quit

7/0.RAM Disk:>