- Home /
How to debug c++ dll code
If I used a c/c++ dll as a plugin. How would I step into the code when doing a P/Invoke call. Does MonoDevelop support this?
If not, how could I debug the code in my external dll?
Answer by cmberryau · Mar 21, 2013 at 01:09 PM
If you're interested, I found an alternative to writing to text files for debugging unity dll's in development.
It's quite simple, just allocate a standard output console using AllocConsole()
FILE * pConsole;
AllocConsole();
freopen_s(&pConsole, "CONOUT$", "wb", stdout);
Obviously this only works under Windows, and if you hit the close button on the console, it sends the quit message to the main Unity window and kills it.
Edit:
I have a new method of doing this using a reverse invoke from unmanaged code to managed code.
C#:
private delegate void DebugCallback(string message);
[DllImport("UnmanagedCodeTitle")]
private static extern void RegisterDebugCallback(DebugCallback callback);
private void Start()
{
RegisterDebugCallback(new DebugCallback(DebugMethod));
}
private static void DebugMethod(string message)
{
Debug.Log("UnmanagedCodeTitle: " + message);
}
C++:
typedef void(__stdcall * DebugCallback) (const char * str);
DebugCallback gDebugCallback;
extern "C" VOID __declspec(dllexport) RegisterDebugCallback(DebugCallback callback)
{
if (callback)
{
gDebugCallback = callback;
}
}
void DebugInUnity(std::string message)
{
if (gDebugCallback)
{
gDebugCallback(message.c_str());
}
}
Ha! That worked for me in a plain old C .dll: lpsolve55.dll, namely. Thank you so much! With linear program$$anonymous$$g, I really needed that results printed out to the console! In my case, it is totally fine that it only works on Windows, since I need the output during development only, so I've put that code in the x86_64 DLL. This works for both, DEBUG and RELEASE builds of the DLL.
Answer by jverwey · Oct 19, 2010 at 07:35 PM
Using Unity Pro, it is possible to step into native C++ code by opening the DLL project in VS and attaching the debugger to the Unity.exe executable. (Attach to process)
As far as I can tell, it is not possible to debug C# using Visual Studio, one has to use MonoDevelop.
Note also that you cannot debug C# using MonoDevelop while debugging a native DLL with Visual Studio. VS will complain about an access violation. You have to pick your poison.
I have seen other people say this too but I cannot do it myself. I have the VS 2019 project from which I built the native dll and I am trying to attach from this project to Unity.exe after I run the simulation. I have the pdb file as well. Am I missing some setting?
Answer by Cyb3rManiak · Oct 18, 2010 at 08:25 PM
Couldn't say about the step into the code, since I haven't yet had the time to test that point in Unity 3.x.
But before Unity 3.x we still developed dlls to work with Unity. There ARE ways, they're just not as pretty :) Usually I would develop the class in Visual Studio and work only on the connection to Unity - passing variable arrays to and from Unity. This way you can always send debug variables and arrays easily at every step you need. Once that connection is made accessible - it's much easier to work.
Then I continued developing the DLL in C++, test it with Unity, back and forth - each time spending more and more time in Unity, and less and less time in the dll.
At one point we tried opening sockets from the C++ to send text data to Unity, which was listening, just for making debugging easier.
Also - text files are your friend - you can write and append to text files from DLLs. Have a simple script or the unix tool "tail" run from a command prompt window - and show the output of that text file on the screen as it's appended to. live. It's just like using Console.WriteLine - The output updates instantly.
Answer by Lucas Meijer 1 · Nov 04, 2010 at 08:57 PM
you could debug that using visualstudio in windows, or gdb (or xcode using gdb) on mac. make sure to compile your plugin with debug symbols, start up unity, attach your debugger, place a breakpoint in its entrypoint, and you should be good to go.
I can indeed break on functions in gdb, but xcode doesn't find the sources and thus I can't inspect variables, which makes debugging utterly pointless...
Anyone have a clue how to tell gdb where the source code is?
Your answer
