Problem resolved with NetBeans+gdb

Apparently NetBeans is still burdened with some issues when it comes to C++ and gdb integration. I previously described changing the project tool suite from Cygwin to MinGW and back to Cygwin. This came about when gdb just mysteriously stopped working. Then I completely rebuilt my project from scratch. gdb working again. Adding files back to the project one-by-one and checking in changes to source control. Oh no gdb not working again. Back out the last set of changes. gdb still not working !@#$@!#$@!#$#$#@$. Try a new simple project.. gdb working. It must be something I've screwed up in my real project settings. I'm new to NB so looking at the project.xml isn't helping much, but strangely enough I can't even find anything change in my project xml files.  OK, do a clean checkout from source control, even my comments in the log say proudly "gdb is working". But gdb is not working even on a fresh checkout. WTF WTF WTF. OK ... nothing works right on Windows. Set everything up in Ubuntu. gdb working! Curse you Windows you have cost me a week on this stupid issue. Happily debugging my project now. WTF WTF WTF gdb is not working. Try cleaning out the project again. Restart NB. Restart Ubuntu. No joy. Open up  Debugger Console in NB. There's that message again "internal-error: is_thread_state: Assertion `tp' failed" Back to the web.... when I read the phrase 're-add all my watches" in the bug report, it suddenly struck me that it was setting the watches that was killing gdb. (I never made the connection before because I had actually been able to get through a couple runs of the program with the watches working before gdb croaked.)

I guess the upside of all this I got REAL familiar with the project files and settings in NB. Actually, while I was running in Ubuntu, I noticed the ".netbeans" in my home directory, which must be where NB would have stored the debugger configuration i.e. breakpoints, watches, etc. Thus explaining why the gdb fault condition could not be fixed by checking out a fresh copy of the project.

One thing I haven't determined if any of this is related to the fact that I am using the capability of NB to integrate with CUnit.

Cygwin or MinGW with Netbeans?

On Windows, there are two options to use the GNU build system: with Cygwin and MinGW.

There are valid technical reasons why one might prefer MinGW over Cygwin. In fact, there even seems to be some issues with NB and gdb in the Cygwin environment. My first experience with NB seemed to go pretty well - I was able to debug into unit test modules created with the CUnit framework. I did however observe one odd thing in that I was not able to use the Debug 'Run to Cursor' (F4) feature - I get a popup box with the warning message "No source file named D.". I believe this is related to the bug. On my system, gdb -v shows the following:

$ gdb -v
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)

I went ahead and switched the project to Mingw.


Follow instructions to setup MinGW Compilers and Tools.

Now the problems start.

Our project code (target is dsPIC30) is not compatible with gcc 3.4.x.whatever in MinGW for a couple of reasons. One is the use of newer compiler directive "-Wno-attributes". Another is the use of binary literal constants in the code.

Anyway, I  installed GCC 4.3.3 for Windows and it seemed to take care of those issues.

As I mentioned previously, it is necessary to revert to CUnit-2.1-0 to achieve complete integration with NB.

You might think you could try to simply download a pre-built binary of a CUNIT build for windows ... but it is probably linked against different libc libraries that won't be compatible with the MinGW you have installed.

Building CUnit from the sources is straightforward (the "configure-make-install" process) but that does require availability of automake/autoconf tools on your build system. I had to go ahead and Install MSYS DTK 1.0 as per instructions on the MinGW site.  (If you followed the instructions from NetBeans to the letter then you probably did not  "install the DTK or the core files mentioned in the wiki page").

Here we go ... Oh goody, more errors:
configure.in:4: error: Autoconf version 2.58 or higher is required

I found some advice on the web about updating packages in MinGW.

Installed msys-autoconf-2.59.tar.bz2 (updated autoconf to version 2.59. ). In MSYS window:

cd /
tar xvjfp /d/dload/msys-autoconf-2.59.tar.bz2


Compiled and installed CUnit from source (configure --debug)

Add the paths for CUNIT library and headers to my project:
../../../../msys/1.0/local/include
../../../../msys/1.0/local/lib

Now I can debug into the Unit Test module. However, the test runner seems to go out into the weeds. After debugging into CUnit, I find that the code hangs up on the following:

"fprintf(stdout,  ..." f_pTestStartMessageHandler

At this point, I am pretty disgusted with MinGW, give up and go back to Cygwin!

It seems that I have somehow deleted the CUnit libraries and header files that I had previously installed into my Cygwin environment. After rebuilding and reinstalling CUnit, and rebuilding my code, I find that I have some compilation errors in my project which hadn't been there before when trying to run the unit test module (Alt+F6):

build/Debug/Cygwin_4.x-Windows/main_nomain.o: In function `bswap_16':
/usr/include/byteswap.h:20: multiple definition of `_bswap_16'


The errors aren't there when running the main project (F6).

I find that the error is precipitated by the presence of the standard  #include :

#include 

... so if I need to print or open files I'm screwed!.

Better way to access share folder in VirtualBox

I should make an addendum to comments I made some time ago regarding setting up a VirtualBox share folder. At the time, I had found a work around was to simply remount the share folder with the uid/guid of my user account. However, I realized recently that the more better righter way to do this would be add my user to the vboxsf group. This is easy to do:

sudo usermod -a -G vboxsf myuser

The result: VBox can automatically mount the Share Folder, as shown here...

Factoring out some drudgery from Unit Testing

I discovered that there is a nice set of features in NetBeans to automate some (but not nearly all!) of the grunt work associated with software Unit Testing. This is my first experience with NB, and I am very impressed with the degree to which Unit Testing work flow is incorporated into theNetBeans IDE. NB provides built in support for the C Unit Testing Framework (in addition to its own built in "Simple" Unit Testing framework).

Unfortunately, NB doesn't completely work with the latest C Unit (version 2.1.2). I got past this issue by building CUnit 2.1.0 from source code, which may introduce yet another issue. If NB complains that the cunit library is not detected, it is because the C Unit library and/or header files have not been found in the expected locations. The C Unit source is set up to install C Unit libraries and header files under /usr/local by default. Rather than changing the default CU install locations or changing the default path settings in my NB project,  I simply made a couple of sym links to fix things up:

ln -s /usr/local/lib/libcunit.a /lib 
ln -s /usr/local/include/CUnit /usr/include

(or alternatively, just add the lib and include paths under Project Properties C Compiler and Linker configurations, and ignore the warning from NB that cunit library is not detected).

The result...

C Unit reports out through NetBeans!

Update 9/18/2013:
Found this post  advising the use of CUnit 2.1.0 due to incompatibility of output format with NB 7.0
Now running CUnit 2.1.2.with NB 7.3 without issue. CUnit and CPPUnit both installed from Cygwin.

Simulink Fun

In my day job I write software for embedded control systems - actually most of my time in the last few months has been spent spent working with Simulink Coder. I put a question out there several weeks ago, to which a usable answer was provided within a surprisingly short time. However, only in the last few days has my Simulink expertise advanced to the point to where I actually understood how to get this to work. I already knew how to define mpt.Signal objects with attribute ImportedExtern which would pick up the actual definition from legacy code. But objects defined that way would not be accepted by Simulink as inputs to a Table Lookup block. What I finally realized was that those objects must be defined as mpt.Parameter instead. I also discovered that using n-D Lookup Table (instead of the simplified 2-D Lookup Table) offered some additional flexibility, such as allowing input table data of integer type (as opposed to the default double precision type).

Classic arcade (and console) game source code projects

For a while now I have been trying to create the Definitive Galaga Dis-assembly Listing. Naturally I took an interest as to whether anyone had attempted any such similarly pointless and futile endeavor. I posted the initial versions of the code some time ago, but it was very rough. However, I am gratified that it has been noticed by at least a few people.

My reference links for similar projects::

Atari 7800 Source Code and Tool Archives (straight from the dumpsters at Atari!)

Donkey Kong Source Code (for 8-bit Atari comp?) posted by Curt Vendel.

Tempest (found in AtariAge forum)

Commented dis-assemblies of Pacman/MsPacman (go to "Video Game Links")

Analysis of Galaga Sound CPU.

Computer Archeology - lots of info on Galaga and several others.

Pacman Galaga Donkey Kong and several others..

Porting Qbert to GameBoy - no source but interesting commentary.

Boulderdash info by Peter Broadribb now hosted by Maarten Egmond. Not so much source code as much as it is a technical specification (reverse-engineered of course!)

Pacman Documentation.

Bombjack... on Spritesmind, a great reference source for the Sega MegaDrive.

Even those works based on the lowly Atari 2600 VCS are worthy of honor... Here is the Definitive Combat Dis-assembly Listing on AtariAge.

Pac-Man a tribute project.

Code::Blocks Setup

I am a big fan of Code::Blocks IDE, but had only discovered it about a year ago when I started messing around with MAME again, and was looking for a modern GUI front-end for the GNU debugger.

CodeBlocks is an IDE available for Windoze, *NIX, or MAC and released under GPL3. It apparently can support a bunch of different development environments but I have only used it with GNU'ish tool chains, particularly gcc on Linux or MingGW-gcc on WinXP.

CB has its own project manager for building and debugging - however, it can also launch builds which are handled by an external makefile. I chose the latter approach to get started quickly with Mame (it is not a trivial build to setup!) and have continued this way since. In the steps below I will go through the basic setup of the tools and the execution of a command line build, and then proceed to using CodeBlocks to build and debug with gdb.


Outline...
Downloads:
MinGW binary (Mame tools release).
Mame136 Source.
Command line build: follow instructions to do it the easy way.
(Note: I use the Cygwin shell, but need to add the MinGW installed PATH to my environment in order to call MinGW gcc and not the Cygwin gcc. I also include the path to the libexec, but I don't recall the exact reason or reference for doing so... but it works!). However, I don't care to make this a permanent environment change so I just put the following in a script which I "source" (dot operator) into my currently running shell instance:

export PATH=/cygdrive/c/MinGW/bin/:/cygdrive/c/MinGW/libexec/gcc/i686-w64-mingw32/4.4.3/:$PATHAt this point, it should be possible to build Mame from the command line to prove that the tool chain works. DEBUG turns on the internal Mame debug console, and Symbols basically enables the -g option to gcc to enable generation of the symbol table for gdb:
make DEBUG=y SYMBOLS=y emulator

Another useful option is to build the "tiny" configuration, which enables just a handful of drivers and significantly reduces the size of the executable:

make SUBTARGET=tiny DEBUG=y SYMBOLS=y emulator

I may eventually get around to describing the setup for a "tiny" build.
CodeBlocks setup:
Go to tools setup, where you can create a new toolchain configuration, or use, modify, or copy one of the many existing ones. For Windoze/MingGW, I chose to modify the existing "GNU GCC Compiler" tool profile, and simply to change the path to point to my installed MinGW.

Under "Settings/Compiler and Debugger/" and "Toolchain executables" tab:
Set the compilers installation directory to that containing the "bin" of the installed MinGW tool chain (mine lives in c:\MinGW).

The rest of the build configuration is setup by the project file:
Setup name of external makefile to call.
Set name of executable.
Set Build options Make commands.


In case of problems, there may be some helpful hints in this article.

This article may take a few editing sessions to complete so stay tuned...