What are 0xDEADBEEF, 0xFEEEFEEE, 0xCAFEFEED & co. ?

If you stumbled in this post looking looking for detailed answer for any of those mentioned in the title, without further ado, there are more complete explanation at:

• https://en.wikipedia.org/wiki/Hexspeak
• https://en.wikipedia.org/wiki/Magic_number_(programming)#Magic_debug_values

But, if you want to know the big picture, read on ;-)

Chances are, you stumbled here after doing some hardcore debugging and found yourself baffled at the values that showed-up in the CPU registers or in the heap/stack memory. I found the first two values in the title (0xDEADBEEF and a variant of the second, i.e. 0xFEEEFEEEFEEEFEEE) while doing debugging in two different systems. The 0xDEADBEEF was on a System i (Power 5) system and the second one was on a Windows 64-bit machine.

All of these values are debugging-aid value, so to speak. It makes them very visible in the debugger (for those who already know). The purpose is to signal that something went wrong and to give an idea what possibly wrong, i.e. where the error possibly comes from, just with a glance on the debugger. For example, 0xDEADBEEF could mean either the program accessed unitialized (heap?) memory or a NULL pointer is encountered (pointing to uninitialized memory). Anyhow, it means something is wrong with one of your pointer. Similar case is indicated by 0xFEEEFEEE or its 64-bit variant.

These "readable" hexadecimal values are categorized as hexspeak because it looks like a "language" despite being hexadecimal value, i.e. you can read them aloud in English or other intended human language. The most hilarious of them all is 0xB16B00B5 ("Big Boobs"). I wonder who was the Hyper-V project manager at the time this Linux guest signature was determined at Microsoft LoL.

Debugging Cross-Compiled Windows Application (Executable and DLL)

I explained how to cross compile Windows application and DLL in Arch Linux in another post. Now, let's proceed on techniques that you can use to debug the result of the cross compilation. The general steps are as follows:

1. Test the cross-compilation result in Wine (running on Linux of course). If the executable can run in Wine or the DLL can be loaded and (at least) partially executed, then, you may proceed to the next step. Otherwise, double check your cross-compiler as it may emit the wrong kind of executable.
2. Run the executable (and if required all the DLLs) in Windows. First, without a debugger and then within a debugger, should an anomaly (or more) is found during the run(s).
3. In the event that you need a debugger, make sure that the cross compiled version of the code contains debugging symbols. You can use "-g" switch in gcc/g++ to generate the debugging symbol in your GNU cross compiler. 
4. In the event that you need a debugger, make sure your Windows debugger is recent enough that it can parse the debugging symbols in your cross-compiled executables and/or DLLs. Also, make sure that it can handle local variable(s), missing local variable debugging support or inability to display function parameter value(s) indicates that your debugger version probably isn't compatible with the cross-compiler. This is particularly true for gcc/g++ and gdb combination. For gcc/g++ cross compiler, you can use gdb from the nuwen "distribution". It has very recent GDB version. Note: I was caught off-guard by older version of gdb in Windows before because it was still quite usable.

To validate that your gdb version, make sure that your debugger output is similar to this:

Valid GDB output

As you can see in the screenshot above, you can inspect all local variable(s) while inside a breakpoint in a function that clearly has local variable. The debugger also shows the value(s) of the parameter passed to the function (where you set the breakpoint), including the function's implicit this parameter.  If you can't see any of that, it means you are using gdb which is incompatible with the gcc/g++ cross-compiler used to create the executable/DLL. Try finding newer gdb version than the one you're currently using.

You can use gdb "script" to carry-out semiautomatic debugging. The screenshot above shows how to use a gdb script, i.e. by using the source command in gdb. The source command basically tell gdb to parse the command file, i.e. the debugging script as if you're typing the debugging command yourself in gdb. See: https://sourceware.org/gdb/onlinedocs/gdb/Command-Files.html for more info on using command file in gdb. This is the gdb command file used in the screenshot above:

b main.cc:23
b main.cc:24
b main.cc:11
b main.cc:12

Hopefully, this post is helpful for those cross compiling applications to Windows from Linux.