Forum Replies Created
-
Posts
-
Hi,
The -std=c++11 is a compiler option, not a preprocessor macro. Please add it to CXXFLAGS instead and everything should work.
The main reason why MCU settings are global for the project is because they define which sources from the SDK are put into the project. If we wanted to make it per-configuration, we would have to combine those lists from different configurations and exclude some of the files from some configurations, making the entire process significantly more complicated. So we decided to make the MCU-specific settings global and the usual settings like extra include paths per-configuration.
Thanks for letting us know. In this case you do indeed need the old BSP. If you want to use both ones at the same time, you can simply relocate the old one via GUI and change its ID in the bsp.xml file.
We will most likely to that after VisualGDB 5.2 is out around the end of summer. As a workaround you can launch SmarTTY that is built into VisualGDB via VisualGDB.exe /ssh:<connection settings file>.
The connection settings files are located in %APPDATA%\SmarTTY.
Hi,
Yes, you can launch it manually by running “make Debug/<file>.o”. This will force GNU Make to build just one file. The reason why VisualGDB cannot do that conveniently via Ctrl-F7 is that VS does not offer a straight-forward way of doing that for Makefile projects.Hi,
No problem. “Similar, but not quite the same” is the most annoying type of problem.
The “cannot detect target name” message means that VisualGDB was unable to locate the “TARGETNAME := xxx” line in the Makefile and it won’t be able to automatically add the project output to the list of inputs of another project that is referencing it. If you have modified Makefiles manually, this makes sense. If you don’t rely on this feature, you can simply ignore the warning.
Hi,
You can do that via the Debug Settings page (program arguments) or the VisualGDB toolbar. Let us know if you need more details.
Hi,
Yes, you can use that link to download older BSPs. However VisualGDB should have showed a warning that the new SDK is not compatible and suggested regenerating BSP references that should update the library file paths. Did that not happen, or did it not help?
Hi,
OK, if the extern “C” is not the reason, you would need to have a detailed look at what exactly is being linked. Please identify one function that is reported unresolved and then do the following:
- Identify the file where it is defined
- Ensure via the build log that the file is linked into the final binary
- Using the nm tool from your toolchain double-check that the .o file actually defines the function and the name matches the error message
- If this does not help, enable the Map file generation and check the Map file to references to the function.
If nothing helps, please post your map file, your build log and the nm output here along with the function name you are tracing so that we could give further advice.
Hi,
It’s a known limitation and it happens because VisualGDB creates its projects as Makefile projects so Visual Studio can start an external build too when your select “Build All” or start debugging, but it does not have per-file control and cannot do a quick check whether rebuild is necessary. We do have long-term plans of resolving this, but it’s not clear yet whether we can fit it in the next release.
Hi,
If this helps, VisualGDB handles the virtual threads as follows:
- It queries your interface for the registers of each thread
- Then it forces gdb to set current register values to the ones reported by the stub
- Then it asks gdb to list the stack frames
You can diagnose the problem by checking the gdb log to see if VisualGDB sets the registers to the correct values before it asks gdb to list the frames.
GetVirtualThread() is called each time a break happens because VisualGDB does not know which of the threads are still alive.
You might be able to improve the performance if you run your gdb stub remotely, but use Windows gdb from one of our toolchains. It won’t affect the code you build (hence won’t break your certification), but will significantly reduce the latencies for gdb commands.
Hi,
The first error can be caused by the missing ‘extern “C”‘ around the headers if you are using the function from the C++ code.
Regarding the second error, it is hard to tell without a screenshot. Please attach one and we should be able to help you.
Hi,
This makes sense. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.1.4.685.msi
It adds support for the EmbeddedThreadPlugin node in the Linux project properties similar to the embedded ones. Let us know if you encounter any problems with it.
Hi,
Thanks for the details, the CMakeLists.txt location is indeed read-only in this case as the wizard makes no distinction between the root source directory (that will be transferred during builds) and the root build directory (that contains CMakeLists.txt). It’s not very trivial to fix, so we have added a note in the 5.2 fix list, but won’t promise anything at this point. As a workaround you can create an empty CMakeLists.txt in the root directory, create the project and then change the CMakeLists.txt location via VisualGDB Project Properties.
Regarding the second missing file, it looks like a separate issue. Is VisualGDB importing the directory contents directly at the root of the project node (e.g. just <project>\main.cpp rather than <project>\dir1\main.cpp)? If yes, please try creating a new virtual folder for your directory, right-clicking on it and then selecting “Import a directory recursively” so that VisualGDB will import the directory contents there.
