Is there a way or steps to follow to integrate a yocto SDK (standard or extensible) with VSCode? I want to cross-compile, remote connect, and debug a C/C++ application within VSCode for target hardware using a yocto generated Linux image. Is this possible? I know of the bitbake extension but couldn't find one for the SDK. Thank you!
Conservatively, I would say it depends on the level of integration you want to achieve but I use regularly VS Code to edit and build, sometime to debug C applications using a Yocto toolchain, that's really easy for Makefile projects for example.
Assuming you do not ask for Yocto integration into VS Code (I don't know if something exists) but really to use the tools generated by the SDK from Yocto and that you already are familiar with Yocto toolchain usage.
I personally compile on Linux server remotely from a Windows PC. The server contains therefore my projects and the Yocto toolchain.
I use for that the nice Remote SSH extension from Microsoft on VS Code. From there, I can edit easily the files, compile and a terminal is available (that's out of the scope of your question however).
So if working as me or directly in Linux, you can create a Makefile/CMake project for example. The C/C++ VS Code extension is a must have.
Each time you start working, you source the Yocto SDK toolchain and compile directly using make from the terminal window of VSCode. If you want to automatize the build step, you can use the task feature of VS which allows you to launch build script for example.
Regarding the remote connect, the terminal window of VS can also have multiple sub-windows with various connections like SSH to the target. The build script can also use scp to send the generated binary directly to the target but your question is vague regarding what you want to do.
Finally for the debug aspect, GDB is well supported in VS Code and the official doc is a good start as well as the C++ debugging doc.
On the Yocto side, you need to add gdbserver to the image running on the target, it can be done by adding the following to your conf/local.conf:
EXTRA_IMAGE_FEATURES += "tools-debug"
If you want to have debug information for the shared libs on the target, you also need to add:
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
Finally, the SDK must be generated with the same options as the image running on the target and will contain the cross-gdb tool like -gdb to be used on the host side.
So that's possible but requires some setup especially the debug part. As far as I know, there is not a VS Code extension managing all these steps for you automagically.
Related
While I am setting up MinGW-W64 (from sourceforge) exe file (for Windows 10) for C++, it shows a message that it was not downloaded correctly. My best guess is that I have a Anaconda/Jupyter setup having MinGW-W64, and it is making all the fuss. How to set it up for both C++ (VS Code / Code lite) and Python/Jupyter/Anaconda?
Make sure you don't mix versions in environment variables like PATH.
Maybe your download was bad?
Or you may have an antivirus software preventing the installation...
You could try a standalone MinGW-w64 build from https://winlibs.com/, which doesn't requite installation - just extract the archive and point VSCode to it.
We're currently using the Resharper command-line tool 2016.3 on our CI build server to inspect code for issues at build time. It's working pretty well but I still have an issue and I can't find any proper documentation on that : how do I install and configure an extension using the command line. For example, I want to add the Cyclomatic complexity extension to my analysis. Documentation said to use the -x switch with the name of the extension (PowerToys.CyclomaticComplexity). The code inspection runs but the complexity warning aren't included in my result file, probably because the extension isn't installed on my build server which make sense. I don't have VS installed on my build machine (and I would prefer not to have to) so how can I install the extension "manually" ?
Thanks
The command line tools in 2016.3 don't currently fully support loading extensions. This comment in the issue tracker has some steps that might be able to support - basically put the .nupkg of the extension in the product folder. YMMV.
I´m trying to build paraview from source, therefore using:
Windows 7
Visual Studio 2010
Qt 4.8.7
Python 2.7.8
msmpi 7
paraview source, version 5.1.0
In CMake I can choose different options to specify what functionality to include into the build process. I tried different combinations, like setting BUILD_EXAMPLES or PARAVIEW_USE_MPI, respectively. Now I have got following questions:
When I set BUILD_SHARED_LIBS and PARAVIEW_ENABLE_PYTHON as well (besides others), configuring and generating the project with CMake is successful, but compiling in VS fails; it keeps freezing right after starting the compilation. Did anybody experience the same problem and how did you solve it? (By the way, if I unset BUILD_SHARED_LIBS it works, but I don´t want a static build of Paraview).
By using the combination BUILD_EXAMPLES, BUILD_TESTING, PARAVIEW_BUILD_QT_GUI, PARAVIEW_ENABLE_CATALYST, PARAVIEW_ENABLE_PYTHON and PARAVIEW_USE_MPI the same problem as described in 1.) occurs, but that is more or less what I need to use Catalyst to perform in-situ analysis of my FEM simulation. (Incidentally, if I unset BUILD_TESTING in the above combination it works, but I need CTest to test the Catalyst examples as described here. Does anybody now how to fix that problem?
As shown at GitHub, some examples have been updated to work properly in Paraview 4.4. Is my version of Paraview (5.1.0) unsuitable for the Catalyst examples? Is that the reason why VS is always hanging up for particular variable settings in CMake and which version of Paraview is most suitable to get the Catalyst examples going?
I'd appreciate any help!
That's odd! There's no known reason for this. Although I haven't used VS2010 explicitly, we do have dashboards testing with 2013 and I build with VS2015 with no issue.
I'd recommend using the Ninja as the builder rather than the IDE, however. Just run cmake-gui.exe from appropriate VS studio command prompt and pick Ninja as the build generator. Then, to build, just run ninja in the build directory.
I recently started using qemu and it's a great tool when you don't have the required hardware to run your firmware (currently using it for cortex-m3).
Now what I want to do is to do some test coverage with it. I tried using GNUC ARM Eclipse, and I've been successfull compiling and executing the code in qemu, but whenever I add the -fprofile-arcs -ftest-coverage flags (for the project and then for the desired file to run coverage) I am able to create the .gcno file, which means that after executing my code it will generate a .gcda file and then I should be able to see the coverage.
Thtat's where everything goes wrong. I was able to generate a .gcda file but whenever I try to open any of them, eclipse tells me that it wasn't able to open the file because it was null. I've tried replicating the procedure in another computer, but I haven't been successful creating the gcda file (probably different binaries).
At this point I don't really know how to proceed. Should I abandon ARM Eclipse and stick to makefiles (is it possibll to run gcov this way?) or am I missing something really small that is fixable?
PS: I using windows 7 64 bits, the latest versions available on the GNU ARM Eclipse website. Also the idea of doing it via makefiles just occurred to me (it was a stresfull day, it's really late) so I haven't tried it yet, I've only tried executing the code, but without coverage.
As far as I know, qemu is not able to generate DWARF information. But there is a project with the proposal of code coverage with qemu: Couverture Project
When you use qemu as a user space emulator (see also the qemu documentation) you actually can measure the code coverage as usual. In this mode qemu has the full access to the host file system.
For a CMake project you can simply use the CROSSCOMPILING_EMULATOR property of your test executable, e.g.:
if(CMAKE_CROSSCOMPILING)
set_target_properties(mytest
PROPERTIES
CROSSCOMPILING_EMULATOR "qemu-${CMAKE_SYSTEM_PROCESSOR};-L;$ENV{SDKTARGETSYSROOT}"
)
endif()
With this setting ctest will use qemu for running the test and will write the .gcda files to the usual location in your build directory.
I'm having problems debugging a JNI application. I've read several threads in StackOverflow, like this one, this one or this one. I've also tried to start gdb in a separated shell and attach it to the running java process. In both cases, the problem is the same: GDB can't find the sources to debug. Things tried
Add "dir" line to gdbinit, pointing to C++ sources folder
Adding the C++ sources folder to the GDB debbuging configuration in Eclipse, in the "Sources" tab.
Adding set environment LD_LIBRARY_PATH=/path/to/library.so, being library.so the library file built from C++ source files
Attach ddd to the java process, but then I get an error because pthread_join.c is not found in the working directory. I don't have this file in my hard disk. I don't know what is this about.
Nothing worked. I've spent several days on this. I know my bug is in the C++ code called by the JNI wrapper, but I can't debug it. Any hints? If helps, I'm running Eclipse Juno in Debian 7 under a Parallels VM on Mac OS.
Many thanks in advance,
You need to have debug information in your native library. You should pass -g to your compiler and linker to have this information in the executable. You may also want to add -O0.
As an alternative to attaching to the Java process, you can create a C++ app and debug it directly. You just need to link in the functions you want to test. In the main function, create the VM, register the functions with RegisterNatives, and kick off a Java test class the uses them.
Hopefully, the debugger has no problem finding the sources since it is just part of the normal compile/link/debug loop of a C++ app.
I would suggest to start with the latest ADT bundle. You can even download the Mac version, so you will not even need Parallels (see a detailed instructions). Then, choose Debug Android Native Application in launch menu.