Debugging cross-compiled code: Linux->Windows

Question

I'm cross-compiling a project from Linux to target Windows (using mingw). The output is a DLL and p-invoking into it from C# works, but debugging is very difficult. The build outputs a .o file, which can provide symbols to gdb, but basically all I can do there is break on exceptions and find the name of the function that was executing when the exception happened; not even the full stack trace. I can't debug with WinDbg because I don't have .pdb files.

This is an open source project set up to build on Linux; I believe their build process relies on several installed Linux packages to work.

Do I have any options here? Is there a utility that can convert .o files into .pdb? Or some program that can give me more information than gdb when debugging?

Delineation

.o files are object files which contain the machine code for the source(s) it was compiled from. Object files may or may not contain debugging symbols. .pdb are 'program database files' and store debugging information for sources and or Visual Studio projects. If the .o files were not created with debugging turned on then there is no way to create representative .pdb files. – Disbelief

If you do build with debugging turned on, what kind of information can you get? – Delineation

it is filetype dependent(COFF, XCOFF, DWARF2, ELF) and it produces stabs symbol tables, data for backtraces, function descriptions, external variables, macro definitions, line numbers – Disbelief

Are you having trouble using gdb or do you know how to bt and ctrl-C and print but are the files missing the necessary info? – Ottie

Don't think I tried bt yet. Been a while since I was last trying to debug a crash but I'll try it if I ever run into another one of them. – Delineation

Have you seen this post? windbg.info/forum/12-symbol-and-source-files-/… The author seems to provide a good deal of information regarding this topic. – Dried

Answer 1

Try a IDE that support mingw. For example the open source Code::blocks.

Saddle

Could you explain your answer, how does mingw and Code:blocks provide additional debugging? – Disbelief

Many IDE's and editors support using (an external) gdb as a debugger, but present you with a nice source code interface to step through and examine variables. You should be able to attach to an already running process or launch a command line to debug at source level. In your case, you'd attach to the c# program or launch it (of course). When the unmanaged dll loads, the debugger will be notified and it will load the symbols and set breakpoints, etc. – Henleyonthames

I've done it, it works. You won't have symbols for anything managed (the exe you attached the debugger to), but dll's that load in that process can be debugged just like any other native code. – Henleyonthames

Answer 2

Another possibility is to do it manually: compile it with debug symbols, start you application and attach the GDB debugger to it. It is also part of the MingW32 distribution. Then you can set your breakpoints and debug your application

But I guess using Code::Block is more comfortable

By the way, the GCC compiler does not generate pdb files because it is a propietary format

Bazemore

Answer 3

What xpol means is maybe: if you have a complete mingw installation then Code::blocks can use gdb to visualize a debugging session like it is done in Visual Studio or Eclipse. See chapter "Debugger" at http://www.codeblocks.org/features

Tiga

Answer 4

You can generate a .pdb file using cv2pdb.exe from Visual D. This works even for programs not written in D if they were compiled with mingw. Once you've downloaded and installed Visual D cv2pdb.exe can be found at C:\Program Files (x86)\VisualD\cv2pdb\cv2pdb.exe.

You can run cv2pdb.exe against an executable like this:

cv2pdb.exe -n target.exe

This will produce a file called target.pdb. Assuming both target.pdb and target.exe are in the current director, you can then use windbg like this:

windbg -sflags 0x80030377 -y . -z target.dmp

In this case I'm also passing a minidump file as target.dmp. This can be omitted. The -sflags 0x80030377 option tells windbg to load target.pdb even though it thinks it doesn't match target.exe.

Note, that it can take windbg a very long time to load target.pdb. Just wait until it no longer says *BUSY* to the left of the command entry box.

Alternatively you can try DrMinGW.

Dynast