I have a Makefile-powered project in Visual Studio 2010 (uses NAnt, in fact, but that's beside the point).
The output of the build process is a .elf file, and I have a separate, non-VStudio debugger which can be run on that .elf file to debug it.
Building works fine, but when I click the 'debug' button (little green triangle), VStudio fails with "Unable to start program 'XXX.elf'. The specified file is an unrecognized or unsupported binary format"
I'm guessing VStudio is just trying to 'run' the .elf as though it were an .exe, and failing.
What I really want VStudio to do is run "my_debugger.exe XXX.elf" when I press the debug button.
I have tried adding a file association with .elf=>my_debugger.exe
I have updated PATHEXT appropriately as well, and run VStudio under those changes.
Still no luck.
Isn't there somewhere in VStudio where you can specify a custom debug command? I thought there was, but can't find it.
I could just have the build process output a .bat file or something I guess, but this seems silly.
As Jim mentioned you can specify which app to start on run in the project settings (Command field). If you place a debugger there you can pass down your executable as an argument to the debugger being launched (Command Arguments field). This way you can launch the debugger which in turn will launch your executable if the debugger expects any commandline arguments.
MinGW on Windows example:
Command: gdb.exe; Command Arguments: Path\ToMyApp\whatever.exe
will start gdb.exe, gdb.exe will open whatever.exe, parse the debug info and wait for debug instructions.
Command: msys.exe; Command Arguments: gdb.exe Path\ToMyApp\whatever.exe
will start msys.exe, msys.exe will execute "gdb.exe Path\ToMyApp\whatever.exe"
Look at the project properties. Do you have a Debug tab which has a Start Action section giving three choices? Those choices would be: ( ) Start project, (x) Start external program: ... ( ) Start browser with URL.
You can also set the command line arguments and working directory.
Cf. How to: Change the Start Action for Application Debugging
Related
I have successfully built OpenDDS 3.13.2 from source. Here is my environment:
Windows 10
Visual Studio 2017 (re-targeted Solution to SDK 10.0.17763.0)
Tried all Configuration/Platform combinations
I successfully used the configure script from the VS command prompt, built everything by opening the generated solution in the same command prompt, and finally ran the Messenger example (publisher and subscriber), and even configured it to use RTPS successfully.
However, when I try to create my own IDL and use the tao_idl, it crashes. Here's my test (using the proper environment from setenv.cmd):
> tao_idl (no args)
IDL: No input files
Second test:
> tao_idl Test.idl (crashes)
I get no error message, and am unable to locate logs or any indication of what went wrong. The same thing happens when I used opendds_idl.
What is the best approach to debug this, and/or are there pre-built binaries available for the IDL compiler(s) (both TAO and OpenDDS)?
After about a day of troubleshooting, I have determined a solution. Despite being able to call tao_idl and opendds_idl yourself, you should basically never do it. There are a good amount of command-line arguments needed to get both to work, and if they're not present, each exe will crash without the proper reasoning why.
I will add my steps below to create a new basic two-exe pub/sub project using OpenDDS:
Create your own IDL file.
Starting with the DCPS Messenger example, modify the .mpc file, replacing Messenger.idl with your IDL file name.
Create a new file called <your project>.mwc, and add the following contents:
workspace {
// the -relative and -include cmdlines make it so this workspace
// does not have to be in the $DDS_ROOT directory tree.
// tell MPC to substitute our DDS_ROOT environment variables for relative paths
cmdline += -relative DDS_ROOT=$DDS_ROOT
// tell the projects where to find the DDS base projects (*.mpb)
cmdline += -include $DDS_ROOT/MPC/config
}
Open a new VS command-line terminal and run $DDS_ROOT/setenv.cmd, or open a regular terminal if you have those environment variables set via Windows settings.
Navigate to your project directory and call: mwc.pl -type vs2017, replacing "vs2017" as needed for your build tool/IDE.
Open up the generated solution, and retarget it as necessary for your Windows SDK version.
Build the <your project>_IDL project first. If you notice in the output window, it is invoking the tao_idl and opendds_idl commands automatically. You can view the .vcxproj files to see the full command-line arguments that were the original problem.
Modify the publisher.cpp, subscriber.cpp, and DataReaderListenerImpl.cpp files to match your new IDL. Run the example as usual and ta-da!
For completeness, the full commands for both tao_idl and opendds_idl are as follows:
> opendds_idl -Sa -St "<your file>.idl"
> tao_idl -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -Sa -St -I$(DDS_ROOT) "<your file>.idl"
> tao_idl -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -Sa -St -I$(DDS_ROOT) "<your file>TypeSupport.idl"
How to specify the path of generated debug binary file when debug go-lang in vs-code?
I have tried modify launch.json file but not work.
I can debug go programs well now in vs-code, the only problem is each time i finish debug, a debug binary file was generated under my project directory, like the picture below.
I want to know can i specify the directory of generated debug binary file?
I am on mac screen shot of my problem:
This is followed by vscode-go issue 1345: "Delete binary files created by delve after closing the debug session"
delve is the debugger for Golang, or at least it's the one that the Go extension uses.
When you debug something with delve, it creates a large binary file in the current directory. If you debug a main function (dlv debug), you get 'debug'. If you debug a test function (dlv test), you get 'debug.test'.
In normal delve usage, when you're done, you quit delve. Delve then deletes this file. Apparently VSCode gracelessly terminates (SIGKILL?) delve, which means the file sticks around.
So this is studied, but not yet resolved.
Update July 2018: Ramya Rao adds in this issue:
I finally have an update!
Turns out there is a command called Detach that can be called on the delve server which will result in the required clean up of the debug binary that gets generated.
To get this fix before the next update to the Go extension (which will be either Friday or early next week), please follow the below:
Download https://github.com/Microsoft/vscode-go/blob/master/Go-latest.vsix
Run code --install-extension Go-latest.vsix
If the above fails with Error: end of central directory record signature not found, then clone this repo (vsgo) and use the Go-latest.vsix file from the cloned repo
Reload VS Code
The fix worked for me as long as the program being debugged wasn't spawning processes of its own like a web server for which I have logged an upstream issue with delve.
I'd appreciate it if folks here can give the fix a try and share any feedback.
The change you need to do to provide an output path for the generated debug binary is in the launch.json file.
Use the property output in your debug configuration.
Please don't modify the package.json file.
This debug file was generated by delve when debugging and should be deleted after debugging, this seems to be bug of go extension of vs-code, see the link here
I am using QtCreator 4.1rc1 under Windows with the msvc tool chain. The debugger is cdb from the Windows 8.1 SDK. I had the same issue with older versions of QtCreator.
When I debug my application, then there are many messages to the output (and issues) pane in the form
Exception at 0x773596c2, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) (first chance) in WinSCard!SCardTransmit
I understand, that this is to be expected under Windows and those exceptions are actually not a problem. But they pollute the output and issues pane and basically render them useless.
So I tried to get rid of the messages. But failed after hours trying. What I tried is the following:
Use the check box 'Ignore first chance access violation' under Tools->Options->Debugger->CDB
Specifying command line arguments to cdb.exe: -xi
Create a script file for cdb.exe to be used at startup to avoid the warnings. The script contained the commands 'SXI 8010000a; SXI 0000071a; SXI e06d7363'. I tried placing the script in several directories and also specifying it with the command line options -cf or -cfr.
When I run cdb.exe from a command line using the startup script, it works! No exceptions are printed to the console. But when I start it from QtCreator, they are there again.
I assume, that QtCreator is using their own startup scripts and those overwrite the ones I specified.
Has anyone succeeded in hiding those exception outputs under QtCreator with cdb?
This question requires an understanding of both the Window's start command's behavior and a custom gradle ExecTask's handling of it.
Question
Why does start, with an application as a parameter, wait for the application to exit, only when being executed within a gradle ExecTask?
Explanation
From the command line, this works as expected (starts the application and returns, without waiting for the application to exit):
cmd /c myBuildEnvironment.cmd && start "some title for start" devenv.exe my.sln
Pretty simple, it calls a windows batch script to setup the environment and then launches my.sln in Visual Studio. Works just fine, not waiting for Visual Studio to be closed. And, this is what my gradle task is meant to achieve.
The same works "somewhat", using the following gradle ExecTask with start:
/**
* I know that the executable + args is replaced by commandLine. They're
* just there for readability.
*/
task openVsSolution(type: Exec, dependsOn: setupVsSln) {
description 'Opens the VS solution, in the appropriate version of Visual Studio.'
executable 'start'
environment = taskEnv
workingDir '../../src/solution'
args = [vsDevEnv, 'my.sln']
commandLine winCmdPrefix + executable + args
}
Gradle happily reports Build Successful, while Visual Studio remains open.
However, I say "somewhat" because start will actually ignore the executable argument and open my.sln with the default application for it, Microsoft Visual Studio Version Selector. So, after some research, I found that start assumes that the first parameter is the window title, then application, and lastly, the application arguments. So, I tried this:
task openVsSolution(type: Exec, dependsOn: setupVsSln) {
executable 'start'
environment = taskEnv
workingDir '../../src/solution'
args = ['some title for start', vsDevEnv, 'my.sln']
commandLine winCmdPrefix + executable + args
}
Everything works, start used the correct version of Visual Studio's devenv.exe, which varies based on the VC PlatformToolset, but...gradle sits in the background waiting for Visual Studio to close.
Why? How can I achieve all of the desired behavior?
Update
This might be an environmental problem. Apparently, on one dev's machine, the original gradle start task does stay open, as well. So, any invocation of start through gradle waits for it to complete, in a certain environment. The plot thickens...
Gradle is waiting for start to return is my guess, see this post - Run a background job from Gradle. Read also the comment after the answer, this is started from Java so if there is equivalent of & (run in background) for windows, it wouldn't work.
You can also try and wrapping it in a bat file, execute what you want in the bat file in the background then return right away so that gradle would be happy.
Hope this helps.
When I start debug in Netbeans, nothig happens. Output strings don't apper; Pause, Continue, step buttons are inactive (only Stop debug button and restart button are active). Stack window is empty.
I tried to run process in shell and attach to it by Netbeans debug. Message with caption "Debugger error" appeared, it contained a text: \320\235\320\265\321\202 \321\202\320\260\320\272\320\276\320\263\320\276 \321\204\320\260\320\271\320\273\320\260 \320\270\320\273\320\270 \320\272\320\260\321\202\320\260\320\273\320\276\320\263\320\260.
Project is compiled with -g flag; gdb version is: GNU gdb 7.0.1-debian; Netbeans version is 7.1; In DDD tool debug for this program works fine.
In my case the cause was a bad variable in the Watches. I couldn't delete it while debugging was hanging. So I had to open the variables window manually while not building/debugging (Windows -> Debugging -> Variables). After deleting the bad variable, everything was fine.
Basically I deleted all variables, since I couldn't figure out, why gdb or netbeans disliked something like:
(char*)_Foo->Bar->Fail. During the previous debugging run this watch worked fine.