Historically I've had a lot of problems using debuggers in the embedded world. Partly it's the nature of embedded work but it's also the tools. In-Circuit-Emulators used to be the tool of choice and worked extremely well but they're expensive. Serial port based debugging tended to be too slow to be truly useful. Eclipse and the NetBurner platform hold out the promise of debugging over Ethernet with GUI based tools. I've still had limited success but since I recently just went through the exercise again I thought I would document the basic steps (and pitfalls).
Debugging a Device Executable project (as opposed to a library) is pretty straight forward. When you create the project you probably created Release and Debug configurations. The Debug configuration will have set everything up for you correctly. If you didn't create a Debug configuration, it's not too late. Right-click on your project and use the Build Configurations –> Manage… menu option as shown in the image.In the Create New Configuration dialog give your configuration a name ("Debug" is a good choice), select the Default Configuration button and select Debug from the drop down.
Unfortunately, if you want to debug a library things aren't so simple. When I used the default Debug configuration for a library I was unable to set breakpoints. Also, almost all of my code (including the startup code that initializes the debugger) is in a library. The default Debug configuration won't even allow the debugger to initialize because it doesn't define the _DEBUG symbol. Luckily you can do this manually.
Right click on your project and select properties, follow the image to get to the Preprocessor settings for the Debug configuration. Don't forget to select the Debug Configuration using the Configuration: popup at the top (see the topmost green arrow). Click the green plus icon on the right to add a new symbol and type _DEBUG. Now when you rebuild you should notice each file gets compiled with the –D _DEBUG flag. You'll also want to visit the Optimization tab and set the optimization level to None.
Your startup code needs to make a call to the debugger. Make this specific to the debug configuration with an #ifdef. You also need to disable smart traps when you're debugging. The canonical initialization code looks like this:
I commented out the alternate method that can be used to invoke the debugger. I also added a cout statement just so you'll know if you have the _DEBUG symbol defined properly. Then you need to make sure the debug configuration is set up properly.
Using the little green lady bug icon select the Debug Configurations… option. The Debug Configurations dialog will open. Select your project on the left panel. In the right panel select the Debugger tab. You'll notice at the top an option for Stop on startup at:, that should be left unselected. Under the extra tab you can specify how many seconds to wait to connect to the debugger. The default is fairly short so you may want to increase that if you time out when attempting to connect.Finally, use the Connection tab and make sure the IP Address is set to the address of your NetBurner. This often defaults to localhost which is not going to do you any good.
While I can generally get things to work somewhat, I have a lot of trouble setting reliable breakpoints. Any that I set before I run seem to work and I can stop and examine variable and call stacks and other associated data. Once I clear a breakpoint, I can't ever set it again and If I need a new breakpoint I have to stop the debug session (which never stops cleanly) and start over again. This may all be a result of trying to debug libraries or it may be the integration of Eclipse and GDB is just not that solid.