From X-Plane SDK
Jump to: navigation, search
This page was imported from the previous wiki engine. It needs a review and cleanup of formatting. Please see this page for more information.
(This information comes from an email I sent out a while back, and may be invalidated by new releases of CodeWarrior.)

First of all, please understand: CodeWarrior's debugger on OS X is buggy!!!  Also I hope you don't mind, I am CCing x-plane-dev so that anyone else who has CW can take a look at this.

With that in mind the theoretical steps to debugging a plugin in CW on Mac inside x-plane are:

0. Make sure you have the latest CodeWarrior (patches are available on their web site) and the latest developer tools CDs.  The dev tools CD is available via Apple Developer Connection.  If you don't have a working CW-dev tools match, debugging will not work, because secretly CodeWarrior just calls GDB to debug.  (This is why it is so horribly slow.) 1. Build with debug symbols on (make sure the little dot is checked in the bug column for all of the items in your project). 2. Make sure your shared library has a name!!  If it does not have a fragment name (in the PEF settings for the project I think) then CW will not be able to find it and none of your breakpoints will hit.  It took me a while to figure this one out. :-) 3. Copy the .xpl and the .xpl.xSym files into the x-plane plugins folder. 4. Specify x-plane as the target application as you did. 5. Set some break points and launch.  Hopefully you can set a breakpoint in your Xpluginstart routine.

In practice I don't think I have successfully remotely debugged a shlib in a host app on OS X in quite a while, CW's had problems with GDB for the longest time.  I recommend the following practices:

1. If you are developing a cross-platform plugin, do as much debugging on the PC as's debugger works very very well for this!  It can even debug CodeWarrior Win32 DLLS compiled on the Mac.

2. Build standalone test apps for as many major parts of your plugin as possible.  In the case of XSB I have test harnesses for all of the different parts of the sound system; the sound system almost never developers bugs solely in x-plane.  Had I tried to debug it in the sim I would have gone insane, just from sim load time.

3. If you want "breadcrumb-style debugging" (e.g. adding print statements all over the place to dump things) your best bet is to use XPLMReloadPlugins().  You can recompile your plugin and reload it from within x-plane without restarting the sim.  This will give you the fastest turnaround time debugging wise.  In order for this to work, you must make sure your plugin exists cleanly (deallocates resources properly, etc.) but a little cleanup pays off big in being able to use this feature.

Anyway, I hope this helps.  Don't spend more than 1 day fighting with Codewarrior...there are problems sometimes that us users cannot overcome, so better to look for alternatives.  If any other CW alternatives know other tricks to making the debugger happy, please let me know!