- This topic has 9 replies, 2 voices, and was last updated 5 years, 8 months ago by
.
-
Posts
-
Is it possible to specify an executable to use when debugging a shared library on Linux?
I’m building C# code which will P/Invoke to native code. So I want to run mono with my C# code as the argument, and be able to set breakpoints in my VisualGDB-built C++ code which the C# code will eventually load and call.
I can’t figure out how to configure VisualGDB to achieve this. Any help is appreciated.
A bit more detail… My “test” setup has a single VisualGDB (.vgdbcmake) “project” that has a native EXE and native .so being built by VisualGDB. The solution has a managed C# EXE project as well that I want to use as the test-harness for the .so. The native EXE is just there as a test to be sure I can do all-native debugging of my .so (this works great).
I did finally get this to work by doing the following:
- using custom debug steps (before launching debugger) to
- copy my managed EXE to my Linux Target
- copy my native .so to the same directory
- Set the debug settings to:
- Use mono as the debugged executable.
- Sets the managed EXE as the argument (at the location I copied it to)
Then I have to right-click on the .so node in the .vgdbcmake project and choose Debug-> Start New Instance. Then I get a message that says “The project debug settings are not configured to debug the startup or selected target. Do you want to fix the debug settings? (Yes/No)” If you say ‘yes’ here, my settings above are overwritten . So “No”. Then I see: “The project debug settings are not configured to inherit the per-target working directory/program arguments specified via VS Properties. Do you want to fix the debug settings? (Yes/No). Again, “No” for the same reason.
Then it does start up and hit my breakpoint in the .so.
But… this is a bit of a painful startup procedure!
If I remove the native EXE (as VisualGDB seems to really want to use that as the startup EXE), then when I do the Debug->Start New Instance on the .so, I see: “No startup target defined for CMake project. Please define a startup target by right-clicking on it. (“OK”). And then nothing.
Thanks for sharing the details of your setup. Indeed the Advanced CMake Project System expects that the debugged executable would be a part of the CMake project, so that you could easily select it as a startup target via the Solution Explorer.
To support your configuration better, we have added a new command for the top-level CMake project: Add->Add a Debug-only Target. This will allow importing an arbitrary executable on the target machine into the project, as if it was one of the regular CMake targets. Please try this build: VisualGDB-5.4.103.3006.msi
Then the setup for the scenario you described will be much easier:
- Add the mono executable as a debug-only target.
- Set it as a startup target (also set the VisualGDB’s CMake project as a startup project).
- Specify the command-line arguments via VS project properties for that target (not VisualGDB Project Properties for the entire project).
You would still need the custom actions to deploy the managed binaries (long-term we are planning to add a special Solution Explorer folder for deployed artifacts, but it has currently a relatively low priority compared to other scheduled features). If you would like to reuse the custom actions between multiple projects and don’t want to create them from scratch each time, please consider using the reusable action list files (you can create them from the regular custom action GUI).
I installed your updated version, and then followed steps 1 and 2. At step 3, the VS project properties for my /usr/bin/mono solution tree node that was added in step 1 (under the .vgdbcmake project node) does not have any properties in it (attached).
I think this is the properties box you mean… I don’t see anyplace else to put in command line arguments…
Sorry about that, our bug. Please try this build: VisualGDB-5.4.103.3008.msi
Also, with your updated build, if I do try to debug by right-clicking the mono target -> Debug -> Start new instance, I get an error (attachment) that references the “Visual GDB Launcher output” window, but that window is not there (attachment). I have seen this type of error previously, and there was a window with actual output before. Some somehow it is not hooked up in this build for for this particular error. (this is using the 3006 and 3008 builds)
No problem. We have rechecked it and indeed the custom shortcut output pane was not properly shown for some project types due to a recent switch to on-demand initialization of the VisualGDB extension.
We have fixed it in this build: VisualGDB-5.4.103.3009.msi
Build 3009 works better, but now the deploy of my managed exe doesn’t seem to work, failing with a LIBSSH2_ERROR_SCP_PROTOCOL error.
The output window shows:
VisualGDB: Executing predebug actions VisualGDB: Copy file C:\tf\ws1\cmaketest\VS15Linux\ManagedExe\Debug\ManagedExe.exe on local computer to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/ManagedExe.exe on wilvm1 VisualGDB: Copy file /usr/bin/../libShared/libShared.so on wilvm1 to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared.so on wilvm1 VisualGDB: Error: LIBSSH2_ERROR_SCP_PROTOCOL while trying to download /usr/bin/../libShared/libShared.so VisualGDB: Executing postdebug actions VisualGDB: Executing predebug actions VisualGDB: Copy file C:\tf\ws1\cmaketest\VS15Linux\ManagedExe\Debug\ManagedExe.exe on local computer to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/ManagedExe.exe on wilvm1 VisualGDB: Copy file /usr/bin/../libShared/libShared.so on wilvm1 to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared.so on wilvm1 VisualGDB: Error: LIBSSH2_ERROR_SCP_PROTOCOL while trying to download /usr/bin/../libShared/libShared.so VisualGDB: Executing postdebug actions VisualGDB: Executing predebug actions VisualGDB: Copy file C:\tf\ws1\cmaketest\VS15Linux\ManagedExe\Debug\ManagedExe.exe on local computer to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/ManagedExe.exe on wilvm1 VisualGDB: Copy file /usr/bin/../libShared/libShared.so on wilvm1 to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared.so on wilvm1 VisualGDB: Error: LIBSSH2_ERROR_SCP_PROTOCOL while trying to download /usr/bin/../libShared/libShared.so VisualGDB: Executing postdebug actionse output window shows:
Not sure why SSH would not work for these pre-debug copy actions. I can delete the directory on the Linux VM, and VGDB will automatically replace the files for the synchronized directory, so it clearly has SSH access.
Any suggestions?
The “while trying to download” message suggests that you are trying to download a remote file, not upload it. Please double-check your custom action. If you believe it is a bug, please share a screenshot of your setting, or the .vgdbsettings file.
- using custom debug steps (before launching debugger) to
- You must be logged in to reply to this topic.