Debugging techniques for PHP programmers

There are many PHP debugging techniques that can save you countless hours when coding. An effective but basic debugging technique is to simply turn on error reporting. Another slightly more advanced technique involves using print statements, which can help pinpoint more elusive bugs by displaying what is actually going onto the screen. PHPeclipse is an Eclipse plug-in that can highlight common syntax errors and can be used in conjunction with a debugger to set breakpoints.

Setting up

To learn the concepts described in this article, you are going to need PHP, a Web server, and Eclipse. The latest version of PHP supported by the debugger extension is V5.0.3.
We need a Web server to parse the pages you create in PHP and display them to the browser. This article uses Apache V2. However, any Web server will suffice.
To take advantage of some of the debugging techniques in this article, you need to install Eclipse V3.1.1 and the plug-in: PHPeclipse V1.1.8. Since Eclipse requires Java™ technology, you also need to download that.
You also need the debugger module extension for PHP. Installing it is a bit tricky. Carefully follow the instructions for installing the debugger extension. For now, comment out the lines where you are asked to load and configure the extension in PHP in the php.ini file. We’ll uncomment those lines when we’re ready to use the debugger.
See Related topics for download information. Now let's move on to error messages.

Error messages

Error messages are your first line of defense as a developer. You don't want to be developing code in PHP on a server that is not configured to display error messages. However, keep in mind that when your code is debugged and ready to go live, you want to make sure error reporting is turned off because you don't want visitors to your site seeing error messages that may give them enough knowledge to exploit a weakness and hack your site.
You can also use error messages to your advantage because they display the exact line of code that threw or generated an error. This makes debugging a matter of looking at the line number shown on the browser by the generated error and checking that line number in your code. Later, you will see that the PHPeclipse plug-in aides significantly in the development and debugging process by underlining syntax errors on the fly and by marking syntax errors with a red "x" when saving your file.
Let's take a look at how to turn error reporting on in the php.ini file and set the level of error reporting. Then you'll learn how to override these settings in the Apache configuration file.

Error reporting in PHP

There are many configuration settings in the php.ini file. You should already have set up your php.ini file and placed it in the appropriate directory, as shown in the instructions in the Install PHP and Apache V2 on Linux document (see Related topics). There are a couple configuration variables you should know about when debugging your PHP applications. Here they are with their default values:

1 2	display_errors = Off error_reporting = E_ALL

You can discover the current default values of these variables by searching for them in the php.ini file. The purpose of the display_errors variable is self-evident -- it tells PHP whether or not to display errors. The default value is Off. To make your life easier in the development process, however, set this value to On by replacing Off:

1	display_errors = On

The error_reporting variable has a default value of E_ALL. This displays everything from bad coding practices to harmless notices to errors. E_ALL is a little too picky for my liking in the development process because it clutters the browser output by displaying notices on the screen for small things like uninitialized variables. I prefer to see the errors, any bad coding practices, but not the harmless notices. Therefore, replace the default value of error_reporting as follows:

1	error_reporting = E_ALL & ~E_NOTICE

Restart Apache, and you're all set. Next, you'll learn how to do the same thing on Apache.

Error reporting in the server

Depending on what Apache is doing, turning error reporting on in PHP may not work because you may have multiple PHP versions on your computer. It's sometimes hard to tell which PHP version Apache is pointing to because Apache can only look at one php.ini file. Not knowing which php.ini file Apache is using to configure itself is a security problem. However, there is a way to configure PHP variables in Apache to guarantee the setting of the correct error levels.
Also, it's good to know how to set these configuration variables on the server side to veto or pre-empt the php.ini file, providing a greater level of security.
You should already have toyed with basic configurations in the http.conf file at <apache2-install-dir>/conf/httpd.conf when you configured Apache.
To do the same as you just did in the php.ini file, add the following lines to your httpd.conf to override any and all php.ini files:

1 2	php_flag  display_errors        on php_value error_reporting       2039

This overrides the flag you have set for display_errors in the php.ini file, as well as the value of error_reporting. The value 2039 stands for E_ALL & ~E_NOTICE. If you prefer E_ALL, set the value to 2047, instead. Again, make sure you restart Apache.
Next, we'll test error reporting on your server.

Testing error reporting

You will save a great deal of time if you leave error reporting enabled. Errors in PHP point you right to the error in your code. Create a simple PHP file, test.php, and define it as shown in Listing 1.

Listing 1. A simple PHP that generates an error

1 2 3 4 5

<?php print("The next line generates an error.<br>"); printaline("PLEASE?"); print("This will not be displayed due to the above error."); ?>

The first print() statement should display its contents to the Web browser. However, the second statement generates and displays an error to the Web page. This results in the last print() statement do nothing, as shown in Figure 1.

Figure 1. Generating an error

You have error reporting turned on! Next, we use print statements to help debug applications.

Introducing print statements

Because functional bugs in your application don't generate errors, knowledge on how to accurately place and use print or die statements to debug your PHP application can be a great asset in your arsenal of debugging strategies. You can use print statements to narrow down the locations of problem statements in your code that may not be syntactically incorrect or bugs in the code, but they are bugs in the functionality of your code. These are the hardest bugs to find and debug because they throw no errors. You only know that what is being displayed to the browser isn't what you intended, or that what you thought was being stored in your database isn't being stored at all.
Suppose you are processing form data sent in via a GET request and want to display the information to the browser, but for whatever reason, the data is either not being submitted properly, or it isn't being read from the GET request properly. To debug such a problem, it's important to know what the value of the variable is, using a print() or a die() statement.
The die() statement halts program execution and displays text to the Web browser. The die() statement is particularly useful if you don't want to have to comment out your code, and you only want everything up to the error and the error displayed and nothing after.
Let's test this concept of using print statements in PHP.

Debugging using print statements

In my years as a programmer where I developed applications on Linux® boxes with no handy GUI to tell me where my bugs were, I quickly caught on that the more print statements I laced my program with the more chances I had of narrowing down the bugs in my application to a single line. Create another PHP file, test2.php, and define it as shown in Listing 2.

Listing 2. Display all variables submitted via GET

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<?php  $j = "";  print("Lets retrieve all the variables submitted to this ");  print("script via a GET request:<br>");  foreach($_GET as $key => $i){      print("$key=$j<br>");  }  if($_GET['Submit'] == "Send GET Request")      $j = "done!<br>"; ?> <form method="GET">      Name: <input name="name"><br>      Email: <input name="email" size="25"><br>      <input name="Submit" type="submit" value="Send GET Request"> </form>

You may be able to spot the bug in Listing 2 very easily. Good for you! Note that this is a simple script, and is shown as an example in using print statements to debug. The script simply takes all variables in the GET request, if any, and displays them back to the browser. A form is also supplied for you to send variables to the server using a GET request for testing. See the output, as shown in Figure 2.

Figure 2. Output of test2.php

Now click the Send GET Request button. Notice that only the keys of the $_GET request got displayed to the browser, and the correct values did not. You can place a print statement within the loop to verify that data indeed exists at each element in the foreach loop. See Listing 3.

Listing 3. Using a print statement to verify code functionality

1 2 3 4 5 6

...  foreach($_GET as $key => $i){      print("Correct data? " . $_GET[$key] . "<br>");      print("$key=$j<br>");  } ...

The placed print statement is in bold font. Notice that you already know that the displayed $key values on the Web browser are correct, but for some reason, the values aren't being displayed correctly. See the new output, as shown in Figure 3.

Figure 3. Output of modified test2.php

Now you know that your application is receiving the variables in the GET request correctly, so there must be a bug in your code. You look over and notice that the variable you are using for displaying the values, $j, is the wrong one. You specified $i in the foreach statement, which must have the correct values, but you accidentally typed in $j. You quickly fix the problem by replacing $j with $i and see the correct output by reloading the page, as shown in Figure 4.

Figure 4. Output of fixed test2.php

You can now remove or comment out the print statement you added because you have discovered the bug in your code. Notice that this is a small subset of the many errors you might experience while debugging your application. A good solution to a problem you may encounter when working with a database is to print out your SQL statements to make sure that what you are executing SQL you intended to execute.
Now you'll take a look at using the Eclipse IDE and the PHPeclipse plug-in and debugger extension to further aid you in your debugging ventures.

Using PHPeclipse

You have probably used Eclipse, but you aren't familiar with it. See Related topics for introductions to the Eclipse platform.
The PHPeclipse plug-in for Eclipse is a popular tool used for developing PHP applications. Start Eclipse and specify your workspace directory as the www directory for Apache (c:\www on my machine). Now click on File > New > Project. The New Project wizard will pop up. Double-click on the PHP folder and select PHP Project. Click Next, enter a project name, debugArticle, and click Finish.
If you set up your Web server to listen to port 80, you don't need to change anything. Otherwise, go to the Navigator window and right-click on your PHP project, debugArticle. Select Properties, then click PHP Project Settings. Click Configure Workspace Settings and change localhost appropriately or add the port your Web server is listening on (http://localhost:8080, for example). Click Apply and you're set.
The Navigator Window should display your project and a single .project file. Right-click on your project as you did before, except this time select New > PHP File. Replace *.php with the name of the PHP file you want to create, test3.php, and click Finish. A new file should appear in the Eclipse IDE. You may have to navigate the bottom window to the PHP Browser to view the current output of your PHP file (see Figure 5).

Figure 5. The PHPeclipse plug-in for Eclipse

Note that only Windows® users can use the PHP browser as shown in Listing 5. The exact same functionality can be used by opening up a separate browser window and pointing your browser to the directory where your test scripts are located.
Now let's demo this application and prove its awesome capabilities.
In the Using the debugger section, you will learn how to debug your PHP application using Eclipse, PHPeclipse and the debugger PHP extension downloaded earlier. You'll start by learning how to use its syntax parsing abilities.

Syntax parsing and underlining

Let's start by seeing how PHPeclipse provides you with real-time syntax parsing abilities to assist you with debugging PHP applications. To see this feature in action, start by defining the test3.php file in Eclipse, as shown below.

1 2 3

<?php print(,"Hello World!"); ?>

Notice that two characters underlined in Listing 4 get underlined in Eclipse, notifying you of incorrect syntax. Saving the file by pressing Ctrl+S displays the Parse error in Eclipse by placing a red "x" by the line that matches the parse error in your code, as shown in Figure 6.

Figure 6. Syntax error highlighting

Now let's demo the PHP browser. This window gives you a preview of the current PHP script, as shown in Figure 6.
Remove the comma (,) from test3.php, defined above. Save the file by pressing Ctrl+S, and watch the PHP browser window update by displaying Hello World (see Figure 7).

Figure 7. Previewing PHP scripts in PHPeclipse

Next up is setting breakpoints in PHP using the debugger.

Using the debugger

Using the debugger, you can set breakpoints and see the browser output from your PHP code up to the breakpoint you set. You can then resume code execution and see the rest of the browser output up to the next breakpoint and the next until your PHP script has completed.
Uncomment the lines you commented out in the php.ini file in the Setting up section and restart Apache. The debugger is loaded, and Eclipse will be able to hook into it.
Now let's set up the debug environment in Eclipse. Create a new test4.php file and leave it empty for now. Now click Run > Debug. Select PHP DBG Script on the left-side panel and click New. Now go to the File tab, and type in your current project, debugArticle, and the file you want to debug, test4.php. Now go to the Environment tab, then to the Interpreter subtab. Browse for your php.exe file in your PHP install directory (mine is c:\apps\php5.0.3\php.exe). Now click on the Remote Debug subtab, select Remote Debug, and if you're not using Windows, uncheck the "Open with DBGSession URL in internal Browser box." Set the Remote Source path equal to the absolute path (not the Web path) to the PHP script you're going to test (I have mine set to c:\www\debugArticle\test4.php). Now click Debug.
The Debug perspective should load, as shown in Figure 8. Otherwise, click Window > Open Perspective > Other, and select Debug.

Figure 8. Debug perspective in Eclipse

Now you're ready to set breakpoints.
With the versions of the plug-in and extension used in this article, a breakpoint function is required because PHP buffers output before sending it to the browser. Besides that, you need to do more than set a breakpoint to flush the current display data to your Web browser, so define your test4.php file, as shown below and in Figure 8 above.

Listing 4. Setting and creating breakpoints

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<?php function break-point(){     ob_flush();     flush();     sleep(.1);     debugBreak(); } print("This will get shown first, "); print("as will this<br>"); breakpoint(); print("This won't get shown until after "); print("continuing the break-point<br>"); breakpoint(); print("END!"); ?

The breakpoint() function flushes output buffered and any other buffered data to the Web browser. The call to sleep(.1) is necessary so the server has enough time to flush the data out to the Web browser before code execution is halted at debugBreak(), a function known internally to the PHP debugger extension you downloaded earlier. Thus, calling breakpoint() flushes data from HTML blocks, print() and echo() statements to the browser, then halts code execution.
After you have written the code shown in Listing 4, you can open a browser and point to test4.php or you can look at the PHP browser window (http://localhost/debugArticle/test4.php for me). Each time you type and save the file, the debugging sequence is already initiated in the PHP browser window. If you are not using Windows, look at test4.php through your browser. After saving your file, resume code execution with F8 or by clicking Run > Resume. Do this until you see END! as the last line of output (see figures 9, 10 and 11).

Figure 9. Initial PHP browser output up to first breakpoint

Notice how the Debug window in Figure 9 shows the execution output as suspended.

Figure 10. PHP browser output after first breakpoint and before second breakpoint

The Debug window in Figure 10 still shows execution as suspended and the second set of data is shown in the PHP browser.

Figure 11. Full PHP browser output

Notice that the code is no longer suspended in the Debug window in Figure 11, and the entire script has executed, as shown in the PHP browser of Figure 11.
Since you have witnessed the advantages of developing with PHPeclipse and the debugger extension, you'll wonder how you ever got along without it.

Summary

Now that you have added the use of error reporting, print statements, PHPeclipse, and the debugger extension to your arsenal of debugging techniques in PHP, you will become a more effective PHP coder by reducing the number of errors you create per line of code. See Related topics for some PHP tutorials on which to test your new skills.

Debug

How to Debug in PHP

Nobody enjoys the process of debugging their code. If you want to build killer web apps though, it’s vital that you understand the process thoroughly.
This article breaks down the fundamentals of debugging in PHP, helps you understand PHP’s error messages and introduces you to some useful tools to help make the process a little less painful.

Doing your Ground Work

It is important that you configure PHP correctly and write your code in such a way that it produces meaningful errors at the right time. For example, it is generally good practice to turn on a verbose level of error reporting on your development platform. This probably isn’t such a great idea, however, on your production server(s). In a live environment you neither want to confuse a genuine user or give malicious users too much information about the inner-workings of your site.
So, with that in mind lets talk about the all too common “I’m getting no error message” issue. This is normally caused by a syntax error on a platform where the developer has not done their ground work properly. First, you should turn display_errors on. This can be done either in your php.ini file or at the head of your code like this:
<?php
ini_set('display_errors', 'On');
Tip: In these code examples I omit the closing (?>) PHP tag. It is generally considered good practice to do so in files which contain only PHP code in order to avoid accidental injection of white space and the all too common “headers already sent” error.
Next, you will need to set an error reporting level. As default PHP 4 and 5 do not show PHP notices which can be important in debugging your code (more on that shortly). Notices are generated by PHP whether they are displayed or not, so deploying code with twenty notices being generated has an impact upon the overhead of your site. So, to ensure notices are displayed, set your error reporting level either in your php.ini or amend your runtime code to look like this:
<?php
ini_set('display_errors', 'On');
error_reporting(E_ALL);
Tip: E_ALL is a constant so don’t make the mistake of enclosing it in quotation marks.
With PHP 5 it’s also a good idea to turn on the E_STRICT level of error reporting. E_STRICT is useful for ensuring you’re coding using the best possible standards. For example E_STRICT helps by warning you that you’re using a deprecated function. Here’s how to enable it at runtime:
<?php
ini_set('display_errors', 'On');
error_reporting(E_ALL | E_STRICT);
It is also worth mentioning that on your development platform it is often a good idea to make these changes in your php.ini file rather than at the runtime. This is because if you experience a syntax error with these options set in your code and not in the php.ini you may, depending on your set up, be presented with a blank page. Likewise, it is worth noting that if you’re setting these values in your code, a conditional statement might be a good idea to avoid these settings accidentally being deployed to a live environment.

What Type of Error am I Looking at?

As with most languages, PHP’s errors may appear somewhat esoteric, but there are in fact only four key types of error that you need to remember:

1. Syntax Errors

Syntactical errors or parse errors are generally caused by a typo in your code. For example a missing semicolon, quotation mark, brace or parentheses. When you encounter a syntax error you will receive an error similar to this:
Parse error: syntax error, unexpected T_ECHO in /Document/Root/example.php on line 6
In this instance it is important that you check the line above the line quoted in the error (in this case line 5) because while PHP has encountered something unexpected on line 6, it is common that it is a typo on the line above causing the error. Here’s an example:
<?php
ini_set('display_errors', 'On');
error_reporting(E_ALL);
$sSiteName = “Treehouse Blog”
echo $sSiteName;
In this example I have omitted the semi-colon from line 5, however, PHP has reported an error occurred on line 6. Looking one line above you can spot and rectify the problem.
Tip: In this example I am using Hungarian Notation. Adopting this coding standard can aid with debugging code while working collaboratively or on a piece of code you wrote some time ago. The leading letter denoting the variable type means that determining a variable type is very quick and simple. This can aid in spotting irregularities which can also help highlight any potential logic errors.

2. Warnings

Warnings aren’t deal breakers like syntax errors. PHP can cope with a warning, however, it knows that you probably made a mistake somewhere and is notifying you about it. Warnings often appear for the following reasons:

1. Headers already sent. Try checking for white space at the head of your code or in files you’re including.
2. You’re passing an incorrect number of parameters to a function.
3. Incorrect path names when including files.

3. Notices

Notices aren’t going to halt the execution of your code either, but they can be very important in tracking down a pesky bug. Often you’ll find that code that’s working perfectly happily in a production environment starts throwing out notices when you set error_reporting to E_ALL.
A common notice you’ll encounter during development is:
>Notice: Undefined index: FullName in /Document/Root/views/userdetails.phtml on line 55
This information can be extremely useful in debugging your application. Say you’ve done a simple database query and pulled a row of user data from a table. For presentation in your view you’ve assigned the details to an array called $aUserDetails. However, when you echo $aUserDetails[‘FirstName’] on line 55 there’s no output and PHP throws the notice above. In this instance the notice you receive can really help.
PHP has helpfully told us that the FirstName key is undefined so we know that this isn’t a case of the database record being NULL. However, perhaps we should check our SQL statement to ensure we’ve actually retrieved the user’s first name from the database. In this case, the notice has helped us rule out a potential issue which has in turn steered us towards the likely source of our problem. Without the notice our likely first stop would have been the database record, followed by tracing back through our logic to eventually find our omission in the SQL.

4. Fatal Errors

Fatal Errors sound the most painful of the four but are in fact often the easiest to resolve. What it means, in short, is that PHP understands what you’ve asked it to do but can’t carry out the request. Your syntax is correct, you’re speaking its language but PHP doesn’t have what it needs to comply. The most common fatal error is an undefined class or function and the error generated normally points straight to the root of the problem:
Fatal error: Call to undefined function create() in /Document/Root/example.php on line 23

Using var_dump() to Aid Your Debugging

var_dump() is a native PHP function which displays structured, humanly readable, information about one (or more) expressions. This is particularly useful when dealing with arrays and objects as var_dump() displays their structure recursively giving you the best possible picture of what’s going on. Here’s an example of how to use var_dump() in context:
Below I have created an array of scores achieved by users but one value in my array is subtly distinct from the others, var_dump() can help us discover that distinction.

<?php ini_set('display_errors', 'On'); error_reporting(E_ALL); $aUserScores = array('Ben' => 7,'Linda' => 4,'Tony' => 5,'Alice' => '9'); echo '<pre>'; var_dump($aUserScores); echo '</pre>';

Tip: Wrap var_dump() in <pre> tags to aid readability.
The output from var_dump() will look like this:

array(4) { ["Ben"]=> int(7) ["Linda"]=> int(4) ["Tony"]=> int(5) ["Alice"]=> string(1) "9" }

As you can see var_dump tells us that $aUserScores is an array with four key/value pairs. Ben, Linda, and Tony all have their values (or scores) stored as integers. However, Alice is showing up as a string of one character in length.
If we return to my code, we can see that I have mistakenly wrapped Alice’s score of 9 in quotation marks causing PHP to interpret it as a string. Now, this mistake won’t have a massively adverse effect, however, it does demonstrate the power of var_dump() in helping us get better visibility of our arrays and objects.
While this is a very basic example of how var_dump() functions it can similarly be used to inspect large multi-dimensional arrays or objects. It is particularly useful in discovering if you have the correct data returned from a database query or when exploring a JSON response from say, Twitter:
<?php
ini_set('display_errors', 'On');
error_reporting(E_ALL);
$sJsonUrl = ‘http://search.twitter.com/trends.json’;
$sJson = file_get_contents($sJsonUrl,0,NULL,NULL);
$oTrends = json_decode($sJson);
echo ‘<pre>’;
var_dump($oTrends);
echo ‘</pre>’;

Useful Tools to Consider when Debugging

Finally, I want to point out a couple of useful tools that I’ve used to help me in the debugging process. I won’t go into detail about installing and configuring these extensions and add-ons, but I wanted to mention them because they can really make our lives easier.

Xdebug

Xdebug is a PHP extension that aims to lend a helping hand in the process of debugging your applications. Xdebug offers features like:

• Automatic stack trace upon error
• Function call logging
• Display features such as enhanced var_dump() output and code coverage information.

Xdebug is highly configurable and adaptable to a variety of situations. For example, stack traces (which are extremely useful for monitoring what your application is doing and when) can be configured to four different levels of detail. This means that you can adjust the sensitivity of Xdebug’s output helping you to get granular information about your app’s activity.
Stack traces show you where errors occur, allow you to trace function calls and detail the originating line numbers of these events. All of which is fantastic information for debugging your code.
Tip: As default Xdebug limits var_dump() output to three levels of recursion. You may want to change this in your xdebug.ini file by setting the xdebug.var_display_max_depth to equal a number that makes sense for your needs.
Check out Xdebug’s installation guide to get started.

FirePHP

For all you FireBug fans out there, FirePHP is a really useful little PHP library and Firefox add-on that can really help with AJAX development.
Essentially FirePHP enables you to log debug information to the Firebug console using a simple method call like so:
<?php
$sSql = 'SELECT * FROM tbl';
FB::log('SQL query: ' . $sSql);
In an instance where I’m making an AJAX search request, for example, it might be useful to pass back the SQL string my code is constructing in order that I can ensure my code is behaving correctly. All data logged to the Firebug console is sent via response headers and therefore doesn’t affect the page being rendered by the browser.
Warning: As with all debug information, this kind of data shouldn’t be for public consumption. The downside of having to add the FirePHP method calls into your PHP is that before you go live you will either have to strip all these calls out or set up an environment based conditional statement which establishes whether or not to include the debug code.
You can install the Firefox add-on at FirePHP’s website and also grab the PHP libs there too. Oh, and don’t forget if you haven’t already installed FireBug, you’ll need that too.

In Conclusion…

Hopefully, during the course of this article you have learned how to do your groundwork by preparing PHP for the debugging process; recognize and deal with the four key PHP error types and use var_dump() to your advantage. Likewise, I hope that you will find Xdebug and FirePHP useful and that they will make your life easier during your development cycle.
As I’ve already mentioned, and I really can’t say this enough, always remember to remove or suppress your debug output when you put your sites into production, after all, there’s nothing worse than all your users being able to read about your errors in excruciating detail.
Got a great debugging tip to share? Do you use a great little PHP extension that makes your bug trapping life easier? Please tell us about them in comments below!
This Article was written by Kieran Masterton.

How to get useful error messages in PHP?

For syntax errors, you need to enable error display in the php.ini. By default these are turned off because you don't want a "customer" seeing the error messages. Check this page in the PHP documentation for information on the 2 directives: error_reporting and display_errors. display_errors is probably the one you want to change. If you can't modify the php.ini, you can also add the following lines to an .htaccess file:

php_flag  display_errors        on
php_value error_reporting       2039

You may want to consider using the value of E_ALL (as mentioned by Gumbo) for your version of PHP for error_reporting to get all of the errors. more info
3 other items: (1) You can check the error log file as it will have all of the errors (unless logging has been disabled). (2) Adding the following 2 lines will help you debug errors that are not syntax errors:

error_reporting(-1);
ini_set('display_errors', 'On');

(3) Another option is to use an editor that checks for errors when you type, such as PhpEd. PhpEd also comes with a debugger which can provide more detailed information. (The PhpEd debugger is very similar to xdebug and integrates directly into the editor so you use 1 program to do everything.)
Cartman's link is also very good: http://www.ibm.com/developerworks/library/os-debug/