Forum Replies Created
-
Posts
-
The ‘@’ syntax definitely works from the regular command prompt. We use it all the time when running pre-release tests on new BSPs and creating custom project templates via our consulting track, so it usually takes less than 10 iterations to find the root cause even for massive projects with very complex settings.
No problem, we can help you get it to work.
Each Linux command executed by VisualGDB runs in a separate shell instance, hence the ‘ulimit’ command specified via the pre-debug steps won’t affect the program (as it will run in a separate shell).
Instead, please try changing the GDB command on the Debug Settings page to the following:
- Command: ulimit
- Arguments: -s <new size> && gdb –interpreter mi $(TargetPath)
- Start debugging with: “run” command
This will launch gdb in the same shell instance as the ulimit command, so it will take effect as desired.
Hi,
VisualGDB allows specifying per-project library directories (see VisualGDB Project Properties -> Arduino -> Extra library directories), so you should be able to achieve the same outcome by using this setting.
If it it doesn’t work, please let us know and we will help.
We also have long-term plans for supporting PlatformIO projects with VisualGDB as well, although it’s hard to name a specific timeline for it yet.
Thanks for the detailed update. Looks like you forgot the ‘@’ symbol before the path to the response file. I.e.
arm-eabi-gcc @.\EmbeddedProject3.link.rsp
instead of:
arm-eabi-gcc .\EmbeddedProject3.link.rsp
Without the ‘@’ symbol, gcc will try to treat the .rsp file as a regular C/C++ source, leading to weird errors. Also normally, you would want to run it from the project directory (some paths in the .rsp file can be relative to it), so the command line will most likely look like this:
arm-eabi-gcc @VisualGDB\Debug\EmbeddedProject3.link.rsp
It could be also something as subtle as a bug in a specific softdevice version, so please ensure that both projects use exactly the same SDK sources/headers (i.e. physically the same files) and the same softdevice binary.
Sorry, we would still need specific steps to reproduce it. You don’t need to attach a whole project, just the contents of the source file (s), the exact place where you trigger the code completion and what do you expect to see vs. actually see will be sufficient.
From the OpenOCD point of view, ST-Link v3 is backward compatible with the previous versions, so simply selecting one of them on the Debug Settings page should work (you will need to switch from USB Devices view to Debug Methods view in order to do that).
We have also added USB VID/PIDs for ST-Link v3 to the device definitions in our development branch, so the next version of our OpenOCD package will recognize them automatically.
Sorry about that. For regular (non-stand-alone) projects there is no redundancy between different types of settings, as we specifically design our BSPs so that the settings specified there do not conflict with the regular VS project properties. The stand-alone projects do give you full control over all flags specified on the BSP level, however it indeed creates a possibility for conflicts.
That said, you don’t need to remember a checklist of flags – simply check VS Project Properties (not VisualGDB Project Properties) -> Configuration Properties -> C/C++ -> Command Line and you will see a detailed list of flags derived from the VS project properties (that will normally override any similar flags from the BSP).
Unfortunately, the exact names of conflicting settings are slightly different between the GCC versions (e.g. newer versions introduce more optimization levels or debug format levels), so reliably checking for all possible conflicts would be a relatively complex and error-prone task. As the scenario you described is relatively rare, we are happy to update the documentation and help you understand the exact logic behind this, however we would like to avoid introducing complex error-prone logic for handling it fully automatically, sorry.
Hi,
Unfortunately the specific connectivity issues you described are indeed beyond the bounds of the regular VisualGDB support, however we can explain what is going on from the VisualGDB’s point of view and suggest some ideas to diagnose it:
- The “stray ‘\'” error happens because VisualGDB tries to compile an assembly file (.S) as Plain C file (following your settings). You can fix this by resetting the “compile as” setting for the .S files (either to default or specifically to preprocessed assembler). The per-file settings will override the per-project setting.
- Normally, you don’t need the “Compile as” option at all, unless you specifically want a file with the .cpp extension to be compiled as a plain C file (in that case, simply changing its extension to .c would have the same effect and a much lower chance of causing confusion in the future).
- As long as you are using C++ without exceptions/RTTI, it should not affect the behavior of other code in the project.
If we understood you correctly, you currently have a project that works and a project that reliably fails (both don’t have any C++ files). We would advise trying to understand the differences between the 2 projects and eliminating them one-by-one, doing a check at each step. Most likely, the difference comes from a slightly different preprocessor macro, different linker script, or even a different order of inputs (unlikely, but sometimes happens).
You can find the command lines used by VisualGDB in the .rsp files inside <project directory>\VisualGDB\Debug. Running arm-eabi-gcc @<path to the rsp file> will result in GCC executing the command line stored in the .rsp file. Please try running those command lines manually (via a bat file) and confirm that the 2 project outputs still behave differently. Then try combining the linker command line from 1 projects with the object files produced by another project. This will show whether the problem happens during linking or compilation. If the problem is due to compilation settings, try pinpointing a specific file by replacing half the files at a time. Once you get to a specific command line, you can repeat the same approach (eliminate half the differences at a time) to quickly identify the exact command line argument that triggers the problem.
Hope this helps. Let us know if you need more details and we will be happy to help.
Sorry, there are no links to the solutions because nobody else has reported anything similar in the past 7 years.
If you would like our help to solve this, please follow exactly the steps below:
- Check if this can be reproduced on a freshly created “LEDBlink” project.
- Check if the problem can be reproduced on a non-VisualGDB C++ project.
If the problem is not specific to VisualGDB projects, it might be caused by something else (you can double-check it by uninstalling VisualGDB). If the problem is specific to VisualGDB projects, please create a video showing the repro, from starting Visual Studio to the problem actually occurring.
No problem. If you get time to attach a screenshot, or a quick video showing the problem, we should be able to help. Unfortunately the description you provided so far, still matches about 5 different problems with completely different steps to diagnose and you probably don’t want to go through them all.
Sorry, looks like there is some misunderstanding going on. Based on your initial question we assumed you were looking for VisualGDB to remember the state of folded code blocks between the sessions (that is not supported).
Just code folding and region folding is a part of VisualGDB and is supposed to work, although it could break if the Clang IntelliSense could not get the necessary information from the low-level Clang logic. We can help you get it to work, however we would need to know the following details about the problem:
- What is the exact project type you are using (Embedded/Linux/ESP-IDF/Arduino/etc)?
- Does the code folding work for a freshly created project of the same type?
- If not, does it work for a freshly created MinGW project (VisualGDB Windows project wizard).
It would also help to see the screenshots illustrating the problem (or a short video demonstrating the problem).
Generally, as VisualGDB includes numerous features and settings, in order to avoid misunderstandings, please consider using the following structure when describing the issues:
- What exact steps you take (from starting VS, not including any existing projects).
- What do you expect to see.
- What do you actually observe.
E.g.:
- Start VS. Create a new Embedded Project Wizard with STM32. In the main file enter the following code:
void testfunc() { if (1) { if (2) { } } } - Expected behavior: the “collapse” box should appear near “testfunc”
- Actual behavior: the box doesn’t appear
This will help us quickly distinguish the problem from many similar issues that could have completely different causes and get back with a fix or a workaround promptly.
As mentioned in our previous reply, unfortunately it is hard to suggest anything specific without the exact steps to reproduce the problem. Please try comparing the setups where the code folding works vs. where it doesn’t and try checking if some specific setting, or some specific sequence of steps triggers the problem. Unfortunately, without having specific steps to reproduce it on our side, we are not able to locate the root cause of the problem and fix it.
Thanks for linking your forum profile to your key. The GDB stub functionality has actually been greatly improved in the ESP8266 2.5.0 core (in the previous versions it was barely usable), however due to some changes to the internal layout, you would need to install VisualGDB 5.4R3 or later (we recommend the latest R4) and ensure you have the latest ESP8266 Arduino core and the latest ESP8266 debug package installed (you can install both via Tools->VisualGDB->Manage VisualGDB Packages).
Then try creating a new Arduino project and ensure you can build and debug it (VisualGDB will set the GDBSTUB_BREAK_ON_INIT=1 variable via VisualGDB Project Properties). Then, simply copy the gdb stub-related code from that project to your project and you should be able to use it.
If gdbstub.h file is empty, it might have been simply corrupted by something else. Deleting and reinstalling the component providing it (if you are not sure, please let us know the full path to that file) should normally resolve it.
If you are not using Arduino, please let us know the exact toolchain and project type you are using (MSBuild, Make, or the new RTOS SDK 3.0 that comes with its own build system) and we will help you get it to work.
No problem. As long as the problem is caused by one of the VisualGDB components and we get enough details to reproduce it on our side, we are usually able to fix it very quickly.
