I'm using Visual Studio 2017 to develop a C++ app on a remote Linux machine. First, I run my code on the remote machine and then attach to the remote process using SSH. I attach to Native (GDB) code and hit my breakpoint. The problem is that I can't view the contents of a string received in the debugger.
std::string msg_str(static_cast<char*>(incoming.data()), incoming.size());
The string above is retrieved via ZeroMQ message. If I do a QuickWatch on msg_str, none of the values are in a human readable form.
What I expect to see is:
{"message":"mark","color":"#FFAABB","session_id":"XVg32B","x":34,"y":563}
What do I need to do in order to view this in the VS2017 debugger?
edit
No I'm not compiling with VS. I'm developing a game using the Urho3D engine. On the Linux box I use cmake to create the makefile and then compile/link using make from a SSH bash shell. In VS I get all kinds of build errors.
I've been searching high and low for more information on how to set this project up, to no avail. My biggest problem is that I'm a C# developer trying to come up to speed with C++. The learning curve is pretty steep...
I think the problem is that you've attached to the remote process and VS doesn't know that it's supposed to be looking at a std::string. Are you able to run your test by building then executing from within VS? Does VS know that the source it can see is what's running in the debugger?
It looks like at least some of the string is visible in QuickWatch as _M_p. The result you expect doesn't appear to be a simple string, could this have a bearing?
I just tried inspecting std::string ss ("12345", 5) in QuickWatch in VS2017 (15.7.3) and the string is displayed exactly as you would expect. But I did compile and run (F5) from VS.
========= 18 June
You can create a makefile project in VCLinux very easily. Add a new project to your solution and choose Visual C++ - Cross Platform - Linux - Makefile Project. Then copy your sources and makefile into the newly created project directory and add them to the VS project. In the project settings, set the Remote Build commands, e.g. cd $(RemoteProjectDir);make debug and under Debugging set the remote command you want executed.
Depending on how complex your project is, it might be worth creating a very simple, stand-alone test to try out remote building and debugging to verify that you can set a breakpoint and correctly visualise a string.
Not the perfect solution, but I do msg_str.c_str() in the immediate window. Probably wouldn't work well for anything beyond the 7bit ascii subset of utf.
Related
Okay I am new to Embedded Linux development.
Right now, I am trying to setup the development environment as efficiently as possible.
I have a python code running on a lightweight Linux based device, that is located remotely
So far I was able to setup my VS Code on my Windows system, in such a way that I can edit the files directly on the remote Linux device.
I followed the instructions below
https://code.visualstudio.com/docs/remote/ssh
https://code.visualstudio.com/docs/remote/ssh-tutorial
Now that I am able to edit my files directly, I face only one obstacle.
I find it hard to traverse to a function/method definition.
In my windows system, I could just Ctrl+LeftClick on a method/function, and it would take me there.
But here when I opened VS Code with the terminal running remotely, I have to do a Ctrl+F and search in the VS Code editor, which is like working on a notepad.
Does anyone know how to get around this?
On my main windows system, I am able to jump to method definitions quickly by Ctrl+LefClick-ing them.
Hope the question is clear enough.
Install the Python extension on the remote server and select the Python interpreter on the Linux device in VS code:
Press Ctrl+Shift+P to bring up the command palette and run the command Python: Select Interpreter.
I'm trying to get started with microsoft's azure sphere development.
When I try to debug any of the starter projects within vs code, it tells me that I have a breakpoint set on the first line of the app.
However, vs code doesn't show any breakpoints in the "Breakpoints" tab.
I am running the latest VS code version (1.44) with the Azure Sphere Extension 20.1 on windows 10. The same problem appears on Linux.
To reproduce the bug:
Download the starter projects from github
Install the Azure sphere extension for visual studio code.
open HelloWorld_HighLevelApp folder in azure-sphere-samples\Samples\HelloWorld\HelloWorld_HighLevelApp in visual studio code.
Go to the Debug tab and hit the green play button on top left corner. Next to the button it should say Launch for Azure Sphere High-Level Applications (gdb)
For me it doesn't an error but the output console shows:
Deploying image...
Starting debugger....
Process /mnt/apps/1689d8b2-c835-2e27-27ad-e894d6d15fa9/bin/app created; pid = 2233
Listening on port 2345
Remote debugging from host 192.168.35.1, port 54911
Starting CMake Hello World application...
The Debug Console shows:
...
Breakpoint 1, main () at ../../main.c:45
45 {
Loaded 'target:/usr/lib/libapplibs.so.0'. Symbols loaded.
Loaded 'target:/lib/libgcc_s.so.1'. Symbols loaded.
Loaded 'target:/usr/lib/libc++runtime.so.1'. Symbols loaded.
Is there a work around / a plan to fix the issue?
Addition 1:
To provide extra clarification here is a screenshot, showing the miss match of console output (breakpoint set) and ui (no breakpoint set)
Azure Sphere uses gdbserver to provide a debug channel to the device. A default behavior of gdb is to break on entering main. This can be confusing to people on Windows who expect a run to breakpoint behavior as is common in Visual Studio. For our interface with GDB we intentionally silently skip the breakpoint on entering main in Visual Studio to be consistent. You can actually see that breakpoint skipped in the debug log output window.
For VS Code we also skip the breakpoint on main when you are on Windows. It looks like you are on Linux from the output above. I haven't used it on Linux for a few weeks so can't recall if the behavior is intentionally different there or not. It would make sense to me to break on entering to main when on Linux as that is the common expectation when using GDB which is more common there than on Windows. I'll check if this is by design or not and reply back, but I suspect it is.
Solution:
Finally I found the root cause of the issue. Visual studio code acts just slightly different when debugging the sphere device compared to just plain c code.
When you start the debugging mode and you haven't set a breakpoint initially, it won't start running your program till you have set a breakpoint. In plain c debugging the program just runs through and printed values are shown in the debug console.
Remote development on Linux from Windows is easily doable via SSH.
However, what about the other way? I need to build and debug my Visual C++ application on Windows, but I want to work on a Linux system.
Cross-compiling via MinGW doesn't work because of MSVC-specific libraries
Ubuntu on Windows is a good start, but I'd like to work on a real Linux system
RDP/VNC or something like that doesn't help either, because than I'd work on Windows again
So does a virtual machine
Maybe something like Powershell on Linux + SSH to the Windows Powershell?
I regularly develop Visual C# applications remotely from Linux, not MSVC for the most part, but, like you, I wanted to find a way to build and debug Windows-targeted applications and libraries on remote Windows machines without working directly in the box using RDP, Visual Studio, etc.
It's difficult to answer this question without more information about the development and debugging tools you prefer to use on Linux for the types of applications you develop. I'll try to provide a general overview and update the answer for details you add about your workflow.
Cygwin, similar to MinGW's MSYS, provides a Unix-like environment for Windows. Most importantly, Cygwin, unlike MinGW/MSYS, includes an implementation of the OpenSSH server that enables us to connect to the Windows box over SSH from Linux (or any other device with an SSH client, really). We can install the sshd package using Cygwin's setup utility. After connecting, Cygwin drops us into a Bash shell by default. With this capability, we can:
Execute remote commands and scripts over SSH.
Edit files using our favorite *nix command-line text editor (Vim, Emacs, etc.)
Mount remote filesystems locally using SSHFS (if Windows shares are unavailable).
Forward or tunnel ports if needed.
The availability of a general-purpose shell makes almost anything possible. We can execute batch files, PowerShell scripts, and native Windows executables from Cygwin's shell environment in addition to Linux scripts and Cygwin programs.
For example, we could run msbuild from the SSH session command line to build our VC++ application or we could configure our local GUI editor or IDE running in Linux to execute msbuild over SSH when we click the "build" button.
We could set up a similar environment in recent versions of Windows using the Windows Subsystem for Linux ("WSL", Bash on Windows). I personally prefer Cygwin for greater portability and ease of configuration. Cygwin's sshd can run as a Windows service, and, as an established project, Cygwin integrates very well with Windows systems (user accounts, filesystems, Windows APIs, etc.).
Working with Code
We can choose from several workflows depending on our tools and comfort-level with the command-line:
Completely text-based—all work performed through the SSH session
Use local tools on files mounted in a remote filesystem
Use local tools and synchronize files
I use the first approach. I'm a heavy Vim user, so I connect to Windows machines over SSH to do my work on the command-line using the tools and environment provided by Cygwin. The availability of tools typically found on Linux simplifies many tasks that are hard to do from the default Windows console. We can write shell scripts to automate tasks that Visual Studio might normally do for us. For example, I wrote a wrapper script around mstest that reads the XML test results and outputs them in a format that's easy to read in a terminal.
If we prefer to use a GUI editor or IDE, we can mount the remote code locally so tools can read and write files as if they were part of the Linux machine's local filesystem. We likely still need to use SSH to execute commands needed to build the projects, but many editors allow us to configure this command as the project's "build" action.
Sometimes a remote filesystem is too slow for effective editing. In these cases, we can synchronize files between the Linux development machine and the Windows host using a tool like rsync or the editor's "upload on save" feature (over SFTP, for example), if available.
Debugging
Everything works pretty well until we try to find a way to debug our applications. As of now, there is no reasonable substitute for Visual Studio's debugger when working with Visual C++ projects. We can debug managed C# applications running on the CLR using MDbg, but no comparable tool exists for C++ programs.
We can try to use gdb (from MinGW, Cygwin, etc.) for basic, low-level debugging of native binaries, like reading memory addresses, but the debugger does not yet support reading Microsoft's debugging symbols, so the debugging experience is very limited. Microsoft began documenting the PDB format a couple years ago, so we may see some compatibility in the future. Even so, it will take a long time to produce a satisfactory alternative to Visual Studio's excellent debugging tools.
For debugging, RDP is currently our best—and probably, only—option. For a more native-feeling experience, we can run Visual Studio using rdesktop (or other RDP client) and seamlessrdp to create a single-window RDP session of the Visual Studio IDE instead of a full desktop which integrates with whatever window manager we're using on Linux.
Sometimes we can get around launching a full Visual Studio debugging session for simple debugging scenarios by adding tracing to our application that outputs values to the console or to a log file. In many cases, this is faster than starting the debugger anyway.
We can also try to use Eclipse's CDT debugger configured for the Visual C++ toolchain. This may enable us to perform remote debugging using an Eclipse instance on the Linux machine. I have never tried this approach, and I expect there may be some issues when the application is linked against Microsoft's libraries.
I don't know all your requirements, but maybe you could use a gdbserver on Windows (from MinGW) and remote debug from VSCode on Linux - or any other environment you like. You can find more details in this post here. (Watch out, VSCode prevents you from running gdb unless it’s signed as mentioned in the first link.)
There is also a Native Debug VSCode extension that could be helpful.
Another solution I can think of is to use Visual Studio Online (free for small teams up to 5 persons) as build server.
As you have said, the other way around is pretty easy and nowadays even officially supported by Visual Studio 2017.
Most probably, the VS remote debugging tools for Windows wont be helpful for you.
I have a C++ application (it's built using Qt 5.8 library and works with PostgreSQL 9.5 database in case it's relevant). The application is build by MSVC 2012 compiler, is 64-bit application and both debug and release versions run normally on their own and under cdb debugger.
When I try to profile the running application by Visual Studio instrument (Analyze -> Profiler -> Attach), it seemingly hangs as soon as it tries to do something meaningful: simply resizing a window or clicking on checkboxes works, but any attempt to compute new values and write them to database never succeeds, as if control flow didn't return from some call.
When I stop the profiling, Studio marks as a "hot path" sequence of calls RtlWalkFrameChain->RtlpWalkFrameChain->RtlpLookupFunctionEntryForStackWalks->RtlLookupFunctionTable->RtlAcquireSRWLockShared.
RtlpWalkFrameChain has the biggest "exclusive samples" count.
Trying to filter data to exclude initial several seconds of run (until the apparent freeze) results in "No Call Tree Data Is Available" message.
I didn't manage to find any article or post with a similar problem.
The project is build in Qt Creator (I don't have a project file Studio would understand, so I can't run "normal" performance analysis).
OS is Windows 7, exact version of Visual Studio is 11.0.61219.00 Update 5.
Any idea on the subject would be welcome.
Upd: When I try to profile the application with Luke Stackwalker profiler, it aborts with the message ERROR: StackWalk64-Endless-Callstack!. The only relevant comment about the message I found is this Stackoverflow question. When I run application under cdb debugger and then try to profile it with Luke Stackwalker, the error message is the same, but subsequent pause in the debugger shows the proper (or at least believable) stack for all threads. For the working thread debugger points to a line of code inside system library and doesn't advance no matter what I do (once again, without profiling attempts the application runs normally, debugger or not).
I'm moved from Windows to Ubuntu Linux, and now I want to set up development environment here. The problem is that I need
C/C++ IDE comparable to Visual Studio
Way to generate Windows PE binaries
Way do debug Windows PE binaries
At first time I tried Code::Blocks. Here I find guide to setting it up for cross-development so I managed to get "Hello World" compiled and running under Wine. Moreover, debugging worked too.
But then I found that Eclipse + CDT plugin is far more advanced IDE. I spent some time and finally get project compiled and linked.
Now I'm trying to get MinGW Insight version of GDB working within Eclipse CDT. Simple way to use debugger described in Code::Blocks guide won't work anymore. I continue to receive "Error creating session" messages.
So my question is, how I can use MinGW GDB under Wine as debugger back-end in Eclipse?
Or, what is best IDE for Linux->Windows cross-development?
I'm wondering that nobody answered this yet.
QtCreator. Don't be confused by its name, QtCreator works is pretty well with any kind of C++ code, you don't need to code in Qt to use it. It is just like FOSS Visual Studio: it does even have a syntax checking "on fly".
MinGW. Here's not much to say, it is just creates Win PE executables, and it works. It is available in repositories. Note, that a Win GUI applications have special bit in it's PE header set; so, in order to create GUI application with MinGW you have to pass an option -mwindows to set this bit.
This is a problem. Really: I'm just trying to debug a windows application, and didn't find yet a way to do it. I will shortly recall here what I tried so far, just in order for you to not step on my rakes:
winedbg. Probably it should work, but for me it didn't. When I set a breakpoint, i.e. like this br 43, it says Unable to add breakpoint (unknown address 7b860807).
winedbg. Yeah, again, but this time we will use it like this winedbg --gbd to make it proxying a commands to gdb. Probably this is the only way to debug an application, but it have a drawbacks: first, in order to restart an application you have to exit debugger; if you enter run it says that the remote target doesn't support this. Second, I have no even idea how to debug a multithreaded application; when I first started this, I stumbled upon an error Non-stop mode requested, but remote does not support non-stop, and after setting a breakpoint and starting it says:
Cannot insert breakpoint 1. and Cannot access memory at address 0x401654. So, in order to make this work I was needed to rename my .gdbinit file (i.e. non-stop mode is set there).
gdb.exe. I was sure that I found a way: simple usage of a windows version of gdb should solve problems; more over, for me, as I am a Emacs guy, it would be absolutely the same as debugging with native gdb. But alas, the windows gdb just didn't work. If I run it, and enter any command, it simply does nothing. It only reacts on Ctrl-c and Ctrl-z commands. Probably I will try on my spare time to ask a question about it on mailing list. Well, now we can't use it...
So what we have do with debug? Most probably seek another Windows debugger that works under WINE. If I correctly recall, OllyDbg worked, but I don't know at the moment how to make it show a source code.
you can try NetBeans.It's a good free, open source
and Cross Platform Support IDE.
Run Windows in a VM?
Seriously, your question is good, but it's probably not worth spending the time to figure out the answer (especially: since nobody seems to have a ready answer). If you have real work to do, native Windows or Windows in a VM is the answer.