How to get around "Binary was not built with debug information"?

Question

I'm trying to debug a C DLL that I'm using with a Delphi program. I built the DLL with Visual C++, with debug information enabled. I built the Delphi program with Delphi 2009, with debug information enabled. But apparently they use different formats, because when I try to attach the VC++ debugger to my program, it says "binary was not built with debug information" and won't even accept as valid the breakpoints I put in the C code, which was built with debug info in the format VC++ understands.

Does anyone know how I can get this to work?

Answer 1

Debug formats are not standardised - basically you can't use Delphi to debug MS compiled code or vice versa.

You can debug Delphi DLLs in Delphi and you can use those DLLs with other apps not compiled with Delphi, provided you mark the Delphi functions for export. What you can't do is debug those DLLs symbolically in a 3rd party debugger, which would have to understand Object Pascal name mangling at the very least.

Answer 2

Not sure about Visual C++ (don't have it installed at all anymore), but maybe this will help...

If you were writing a DLL in Delphi and using it from C++, and you wanted to debug the DLL, you'd open the source for the DLL in Delphi and set a breakpoint. You'd then use Run|Parameters and set the C++ application as the host executable and hit run in the Delphi IDE. The IDE would then launch the C++ application and run it as usual until the breakpoint in the DLL was hit, and then would break as you'd expect.

Is something similar available in VC++? (You didn't say which version of VC++, or which version of Visual Studio or the earlier IDE you were using.)

If not, the only alternative I could think of is to do a quick VC++ app that uses the DLL and debug via that instead.

Answer 3

When you say "won't accept as valid" the debug breakpoints in the C code what do you mean exactly? Does it not enable them? If so has the DLL been loaded yet when you set the breakpoints? I find it can simplify matters if I wait to set the breakpoints until after I'm sure the DLL in question has been loaded. If this is not what is happening, please elaborate on what you mean by "valid" breakpoints.

Other options are to set function breakpoints, or the compile the DLL with strategically placed DebugBreak() calls.

Are you sure it's the right DLL that's being loaded (i.e. the debug version)?. Again, even the right DLL is being loaded I'm not sure the error is necessarily applying to the DLL and not just the main executable. Or it could be having problems loading the symbol database as suggested by jdigital, assuming you extract them out for debug builds of your DLL. Even with no debugging symbols, debugging should still be feasible, especially since it's a DLL, you can work from the exported symbols.

This isn't a COM component is it? If it is, I'd double check that the debug version was the one registered before you start up your process.

Again I'd still be interested in hearing exactly what happens when you try to set a break point. If you go to the breakpoints window in VS it should clarify why the breakpoint couldn't be set, if that's what is happening.

Hmm. I don't have much experience with /Z7, do you still have the .obj file for the DLL? The docs seem to imply that's necessary for debugging. Alternatively I'd try building with /Zi instead and getting a .pdb for that sucker.

Answer 4

Have you pointed the debugger at the symbols for your DLL? If there's any doubt, try running with Filemon to see if the debugger is failing when it tries to load the symbols.

Answer 5

Insure that is opening the DLL in the Debug Folder, not another one in some other folder.